This project is read-only.
3

Closed

Advanced Asteroid Creation

description

These are just some features I would like to see relating to asteroid creation and management.
  1. Allow users to merge two asteroids into one using techniques similar to Constructive Solid Geometry algorithms (Union, Difference, Intersection).
    1B. Allow the removal of the intersection with a station.
  2. Allow users to choose between "Blended", "Merge", and "Natural" options for setting Asteroid material composition during asteroid generation.
    a. "Blended" mimics the current behaviour in SEToolbox with all materials being relatively equally blended at their given ratio.
    b. "Merge" scales and intersects micro/small asteroids with the base asteroid repeatedly until the ore saturation level is close to the desired amount. This creates ore distribution similar to SE's internal way of generating asteroids with a variety of ores.
    c. "Natural" scales intersects custom "vein" voxel maps with the base asteroid until the ore saturation level is close to the desired amount. The result looks a bit more natural and make mining a bit harder as drilling will likely pick up other ores during the process.
    d. "Layered" creates layers of ore like a natural planetary body with rare ore appearing as pockets (not thin layers) within.
  3. Allow users to rotate asteroids.
  4. Provide an option to delete disconnected voxels within a voxel map.
  5. Bounds check on asteroids and alert user of any asteroids that share space.
Closed Feb 2, 2016 at 3:00 AM by midspace
I am closing this issue as it is too old and no longer relevant.

If someone believes this is still required, then a new issue must be logged here:
https://github.com/midspace/SEToolbox/issues/new

comments

ashein wrote Aug 28, 2014 at 12:07 PM

Hey,

I've been trying to make some alternative ore seeder for the asteroids. I've modified the source to substitute the byte-shuffler with a primitive spherical-ish allocator using larger voxel cells. So it mainly just seeds small pixelated spheres and cleans up the outer surface of the roid. The roid field creation window is also changed to accommodate for such variables as the number of ore injections, the radius etc, and the randomizer was altered to fit with this seeder.

It doesn't work with some roids for some reason I still can't define. Some roids just won't accept materials, though at save time the data structure seems fine, at least no visible difference between the normal roids and the faulty ones. SEToolbox also reports resource availability in such roids, whereas forced vox-file resaving they all vanish.

Some examples can be seen here. Notice the classic triangles on some sections and squared segments sometimes - it is possible to smooth them out, but I've never done anything in C# until like three days ago, so apologies for that.

If interested, I can supply my "code" for that. but be warned that it should be quite sub-par in relation to normal standards (huh).

wrote Aug 28, 2014 at 8:32 PM

midspace wrote Aug 29, 2014 at 1:11 AM

Yes, that looks good.
Yes, please send any code through.
Sorry, I'm not in a coherent frame of mind atm, I'm in the grip of cold or flu.

ashein wrote Aug 29, 2014 at 4:55 AM

Submitted a small patch in the corresponding section.
It's based on 044, but I don't see any conflicting changes in relation to the fresher commits.
I'm utterly sorry the contents look like crap and possibly work for me only. I didn't check out from version control in the first place and had to remove the protected keys in order to enable building my local instance, so had to resort to manual patch generation and could have missed something.

Get well.

midspace wrote Aug 31, 2014 at 2:47 AM

I'm having some trouble with the codeplex's patch.
It's not making any sense to me, as their tool says it's supposed to be an xml file, but what I've downloaded is some sort of text comparison.
It'll be far easier for me if you can just zip up whatever you've done and attach it here.
I've got beyond compare, which will do directory and file comparisons to tell me what has changed, making merging much easier, at least in my cold befuddled state.

ashein wrote Aug 31, 2014 at 11:26 AM

Sorry, didn't know there's some special format for patches in Codeplex. For me patches are just these file diffs that can be applied with "patch" CLI tool that's available for SVN or git.

Anyway, had trouble with applying the patch myself, because in Win / Visual Studio there's apparently no instrument to apply these patches (but you can make one in VS, huh). And after getting GNU patch tool I realised that I have forgotten to include one more change there :(

Uploaded an updated current - as of today - revision in the patch section, should work out of the box. And sorry for wasting your time trying to figure out my poor man's code.

ashein wrote Aug 31, 2014 at 11:40 AM

Forgot to mention: in the field creation window the abbreviation "V. N." mean "veins number", "V. R." - veins radius (int, in voxel cells, 0 = just one voxel cell = 512 voxels. Gotta rewrite it to use actual voxels laters, I suppose). So values of 10 and 1 will attempt to create 10 instances of cross-like formations (7 voxcells) of the given material. Some of those cells will quite possibly turn out to be in/near the roid surface, and in that case they will be overwritten by the base material to hide the inner roid contents. Only outer surface area will be reset: the method that's used is quite dumb; the inside cavities will still show seeded materials on the surface.

Sorry this all isn't user-friendly :(

midspace wrote Sep 9, 2014 at 6:36 AM

ashein, I've merged in most of the code, but I haven't enabled it yet as I'm hoping to make the interface more intelligent so the user only has to plug in percents, and then the veins can be calculated automatically depending on the existing volume of the asteroid.

ashein wrote Sep 9, 2014 at 8:10 AM

Yes, I've seen the work you've done separating the filler routines, nice job.
Meanwhile, I've been using the current version with the seed filler and trying to improve on it.
I've modified the two main voxel map methods to use actual voxels instead of full cells for smoother seeding.

Here's pictures of an example asteroid - russian transmitter - from the inner and outer surfaces. Image levels ramped up to better see the spherical deposits.

I had also previously failed in computing the sphere radius, so switched to normal vector length instead of taxicab.
The spherical generator is still largely unoptimized, i.e. it runs through all voxels when seeking those inside the sphere, could easily be switched to bounding box first and save a ton of ticks, so the roid in the examples above took some 90 seconds to generate on my Core i7 2.6Ghz.

The snippet of the two MyVoxelMap methods (+a private one for shortening) can be found in pastebin, if required.

I don't know how the percentage-based input can be provided in this case, really, as only the outer shell composes some 10+% of total voxel, and sometimes a noticeable part of resources gets reset when generated on the surface.

My general aim for this seeder is the ability to provide a way to embed more-or-less precise amounts of resources. Namely uranium so that it could always be in some trace amounts for proper survival gameplay.

ashein wrote Sep 10, 2014 at 8:19 PM

I apologize for my crude code again, but I've been updating the spherical filler method to use a box model. The current result is an order or two of magnitude faster than that in the previous post, so if you need it, it's on pastebin. A skilled coder would have optimized that stuff from the very beginningm yeah, I know.

wrote Oct 5, 2014 at 5:28 AM

Associated with changeset 28803: Fixed sorting on Cubes.
Added ship rotational information, and ability to stop either Linear or Rotation velocity separately.
Fixed low level code on reading Asteroids.
Added rotating of asteroid content.
WIP on merging asteroids.

wrote Oct 10, 2014 at 11:40 PM

wrote Oct 10, 2014 at 11:40 PM

wrote Feb 2, 2016 at 3:00 AM