Posted by MrOMGWTF
on 24 September 2012 - 06:34 AM
An octree is a run-time structure that is created and maintained dynamically. It does not belong in a file, nor can it be used to “store geometric data”. You will have to be more specific accurate about what you want, and you should probably read up on what octrees are.
I think you misunderstood me. I just want to store octrees in my map file for quicker loading times. But I didn't know that octree generating in run time is quick.
Just make it yourself. Be creative You can use xml parser for making your life easier. Example map format:
Posted by MrOMGWTF
on 20 September 2012 - 11:14 AM
Thanks for your replies, guys.
I downloaded the demo on your site, im pretty sure its the same one but I only get a black screen O.o
Sorry to disappoint you but the demo on my site is a bit old and doesn't include these new features. The black screen must be caused by some incompatibility with your graphics card, unfortunately the demo was only tested on an Nvidia GTX 260 so it should work well on any NVidia card above that. Also, make sure you have updated drivers.
How are you choosing your grid bounds? - Is the voxelization done at runtime? I assume no? ("voxelization is performed on the CPU with raytracing") - The intersection generated by the +X ray is injected into the -X 3D texture? - During cone trace, how are you dealing with occlusion? - "which makes them look displaced from the scene even for glossy reflections." What does this mean? Shouldn't Eye <-> Glossy <-> Diffuse <-> Light work?
Also, is there SSAO in those screenshots?
The grid is fixed at the world origin with dimensions of 30x30x30 meters. The voxelization can be redone in runtime but it is not real-time. The raytracing takes about 1 second and inserting the points into the volumes is slow as hell taking about 8 seconds. This step is far from optimized because I'm not even using vertex buffers for rendering the points, I'm rendering them with glBegin/glEnd (shame on me, I know). The intersection generated by the +X ray is not necessarly injected into the -X volume. The rays are cast in all 6 directions only to ensure the voxel representation of the scene has no holes. The injection into the 6 destination volumes depends only on the normal of the point which is what represents the direction of the radiance. Occlusion is dealt by keeping track of the accumulated opacity of all the samples processed for that cone. Think of it as regular transparency blending, where each sample is a semi transparent window that partially occludes the next sample. The reflections don't look good because the voxel representation of the scene contains only direct lighting. So, what you'll see in the reflection is the scene lit by your light sources but being completely black on the shadows. Regarding the SSAO, yes I have it. But the cool thing about this technique is that if you use enough cones you don't even need SSAO since the technique provides that effect for free and with much more realism.
Posted by MrOMGWTF
on 09 September 2012 - 04:48 AM
Hi, I've made a simple test scene for testing global illumination in it. I'm sharing it with you. Here's how it looks (No real GI here, just a directional light + a white-red point light to simulate GI):
You are ray-marching, not ray-tracing, so your rays die after a certain distance travelled (as far as I can guess - you haven't mentioned what you do with your rays) so that would explain the arcing horizon. A perspective projection cannot by definition cause straight lines to appear curved, so the curved horizon doesn't come from the camera - as far as I can tell anyway, the camera code looks fine, although the camera position and direction are hardcoded.
The position isn't hardcoded, there is no rotation. To rotate a camera I have to multiply the ray direction vector by rotation matrix, right?
@edit And yes, I increased the max distance from 100 to 1000, and the plane is now flat. Thanks for the help.