5 ms·
This is a cool project, but something here sounds familiar a) doesn't use a known algorithm like sparse tress or b) a million GB of memory. ...wait a second. I
by shadowmint 13y ago
This is a cool project, but something here sounds familiar a) doesn't use a known algorithm like sparse tress or b) a million GB of memory.
...wait a second. I swear I've heard this before.
Why does everyone who works with voxels act so secretive about how their rendering works?
No one cares.
No one cares.
No one. Cares.
Really. No one is going to steal your clever memory optimizations. They don't care.
If you've done something clever, explain it. Maybe you'll get a hi-5 from someone. Being all, coy about it is just irritating.
- gavanwoolery 13y agoHi - I kind of have explained it a little bit in previous comments here - I was going to go more in depth on my website but last night I was running on very little sleep. Sorry! :) The tricks are actually not that interesting but I guarantee I'm not like the Infinite Detail / Euclideon guys. :) It generates the voxels in GPU memory (About 128 MB of memory is used per chunk) - but once it renders the chunk it immediately dumps the non-critical data and reuses that rendering page. It can still access any visible voxel in the 2D rendering (even the various chunk layers), but to access the internal voxels it has to regenerate the chunk or use the procedural generation algorithm to determine what a given point would be like. Collision detection can still be handled pretty well via the larger chunk properties and the depth properties of the rendered chunk. So the real trick lies in procedural generation and the ability to rapidly recreate chunks as needed. It uses ray-casting on a hexagon shaped like an isometric cube, which is nothing very advanced or new. Let me know if I can answer in more detail - I may do a writeup on the techniques time willing. :)
- shadowmint 13y agoSounds interesting, definitely be interested in a blog post with some details, for example, how it compares to the normal way of doing this sort of stuff (eg. http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsights-SparseVoxelization.pdf http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsig...)
- GuiA 13y agoThanks for posting this. I've had a few toes (ok maybe a foot) in the indie game development world for quite a few years now, and they're definitely amongst the group of developers who are the most averse to putting their shit on github and open sourcing their libraries etc. The game dev community has a love/hate relationship with open source: on one hand a lot of widely used tools are under open source/free software licenses (box2d, SDL, etc.), but on the other hand you'd be hard pressed to find an indie willing to release his source code (Jason Rohrer I love you). There's definitely a technical reason for it (game code is often hacky and not that reusable), but I've observed that it has to do more with the sense of pride of the developers ("my code is too ugly people are going to think I am a bad developer").
- brymaster 13y ago> definitely amongst the group of developers who are the most averse to putting their shit on github and open sourcing their libraries etc Yep. I'm sure the majority of them are also GPL violators. They love to take but never give back.
- tinco 13y agoWell that's a rather harsh accusation. Do you have any evidence to back that up? Since when has "it's nice to share code" turned into "you're probably a criminal if you don't share code".
- brymaster 13y agoThat's a funny question. The plethora of open source code available and the miniscule number of open source 'indie' games suggests something is askew. But one look at today's 'app store' ecosystems and current game dev culture is all the evidence I need. It's a profiteer's paradise.
- tinco 13y agoYour comment is appalling. I wish there were less people like you in the world :)