@pspeed - did you have a chance to move everything over to github yet? I’m interested in taking a look at this as I was going through looking to update my cubes framework, but depending on what you have it may be better to just collaborate.
Not yet. I had to figure out how to break it up into multiple projects first and once I figured that out, I ran out of time.
I will move it at some point.
@sleaker @pspeed
I exported it over a couple weeks ago, the simsilica-tools repository, using the google code exporter.
I would assume it is the complete package with all the functionalities, I haven’t tested it out though.
Thanks @themiddleman - I found pspeed’s original code so having it on git doesn’t help me too much as far as collaboration until @pspeed put’s it up in a place that’s ready to accept PRs/contributions.
Don’t let me forget to do this.
Get it done @pspeed 
“Are we there yet?”
“Are we there yet?”
“Are we there yet?”
“Are we there yet?”
“Are we there yet?”
“Are we there yet?”
1 Like
poke poke @pspeed - Are we there yet? 
Not yet. But soon I hope.
I should be ready to start committing stuff for my networking package soon… and in that case I’ll have wanted to move simsilica tools over to my spot on github.
Edit: keep reminding me, though.
1 Like
@pspeed so, you finally moved it to github, right? Or at least in a process of doing so.
Great work!
I think it’s still local to me. I was looking forward to burn it in a little on a real game but just haven’t gotten anything to the point of play testing.
Well, at least it already compiles and runs, not without some project setup tweaking but nothing more severe than some missing libs or strangely impossible to compile LemurProps, who needs to compile Lemur from source anyway :chimpanzee_winktongue:
I’m going to use it for fast prototyping of my side project so I’ll be capable to provide some, let’s call it “feedback”, if you’re interested in it.
Maybe we were talking about different things. The last post I made in this thread was referring to a networking library.
…though looking, I guess I did commit that to github, too. Everything else has been in github for like 6+ months or so.
Edit: and lemur props compiles fine for me… though the SDK constantly says it has errors. I never trust the SDK built-in incremental compiler because it’s a crappy piece of shi*t… I always turn off ‘compile on save’ and let ant build it (through the SDK).
@pspeed, Definitely. I’m talking about IsoSurface Demo and simsilica tools. I may be a bit late but I only yesterday noticed that you finally moved it to github from archived google code.
Wait a minute, what if we could adjust isosurface to use integer or even short for density instead of float? Considering that we are not on GPU and most interesting usage for marching cubes will be not constructing random world on fly but making said world savable and editable, it may lead to something meaningful, or not.
I’ll try to implement it and don’t stop me even if you already tried something similar 
edit:
First try with short instead of float, fast and dirty. Worldgen completely broken, but everything else works surprisingly well.
edit:
Quick fix for worldgen, just fix for short overflow, needs more love to beautify visuals back to original level.
Why short versus float, though?
If you want fully 3D editable worlds you could just leave them as floats and adjust the values at runtime… kick of a rebuild of the zone, etc…
Else if you just want heightmap based terrain, I have a terrain implementation like that already. I can probably cut and paste it here but I don’t know if it will be useful on its own. I used heightmap (fractally generated) for the Dragonfly Odyssey game I started that was mostly based on the IsoSurface code.
Remember, we are talking about savable and editable map - such a kind of maps that will take space on disk in any case and will be sent trough network at least once per player in case of multiplayer.
So, my main motivation to try replacing float with short is a size - 2b short takes two times less space in a save file than 4b float (compressing could reduce difference a bit but short still performs better).
If worldgen is consistent per chunk (generates the same chunk identically given the same seed, disregarding chunk generation order), then one could save or send only modified chunks, while just generating untouched ones when needed, but it’s not always possible to implement chunk-consistent worldgen.
For simplest implementation even byte density could be enough, leading to even better savings, though not without a price.
Another concern is operations performance difference. While it’s minor on common usage and don’t worth the hassle, on big numbers it strikes back. And what to call a big number if not a count of voxels in infinite voxel-based world (I know, technically we load only a small fraction of chunks around player, but it’s still a lot).
Memory footprint could be potentially reduced by half as well, but it highly depends on VM implementation so can’t be relied on.
Regarding heightmap based terrain - not very interesting for me and easily replicable, but who knows, maybe someone is right now dying without it :chimpanzee_wink:
Anyway, I’m just toying with an interesting for me idea, nothing really that big in mind for now.
But the code pspeed wrote is for meshing an iso surface, you feed it a function that given a coordinate in space says whetever that is “inside” or “outside” (and by how much).
Now, that function might be fed data from a discrete set of points (like you seem to be talking about) but it might equally well be some other algorithm. So I think you are mixing up the meshing algorithm with how to store “world” data on disk. They are only loosely related.
Sorry, but I clearly understand what happens here. There are three main modules:
- Worldgen - simply a 3d-noise function.
- Storage - array of density values in a 3d grid plus interpolation function to sample said values seamless. Exists for every chunk generated by worldgen.
- Mesher - builds a chunk mesh using density values from storage.
You are right, saying that we could use any possible way to fill a storage but you’re wrong thinking that mesher works directly with worldgen. While in theory mesher could work directly on data from worldgen, it does not do so due to fact that 3d noise is not a cheapest function to calculate.
Right now storage is only populated by worldgen and stored in memory, but saving it to a disk is only a matter of streaming it to a file.
And here starts most interesting part - density value is not restricted to small numbers with floating point - what really matters for density is only a sign and how much density of selected point on grid differs from neighbours in % from absolute value. So float is not any better than short from algorithm point of view.
Now I see. But if the conversion from storage data to float is simple then you can leave the mesher as is and just convert your storage data to floats when meshing. You can of course change the mesher to use short if you think it is better.