Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!

We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 12 May 2009
Offline Last Active Jan 30 2014 08:09 AM

Posts I've Made

In Topic: Position and Normals from depth revisited (artifacts/banding)

08 May 2013 - 08:49 AM

I use ogre. Its a render to texture render target with rgba components. Each component is a float32. So total of 32x4 = 128 bits precision.

In Topic: Position and Normals from depth revisited (artifacts/banding)

08 May 2013 - 03:52 AM

Thanks for your reply. However, my question is more geared towards why this really happens.

In Topic: Voxel / Marching Cubes

25 May 2011 - 12:52 AM

1. How is Voxel data usually stored? Is it similar to height-mapped terrain where you can just specify heights and then generate the vertices during run-time?

It could be as simple as a raw 3D array with an associated value. This value can be density (e.g. 0 for air, 1 for solid), or multiple values like density, opacity, material id, etc. It depends on what all scalar quantities you need to represent in the 3D structure.

Marching cubes 'walks' this volume and generates meshes which is what you render with ultimately.

2. How is the large memory footprint handled in a real-time simulation? Are there "chunks" which can be streamed in and out depending on view distance?

A voxel based data structure can run time compress/decompress the stored values using an algorithm like rle, etc, so that run time memory consumption is kept at a minimum. If RAM is not an issue, just disk space, then merely zipping up the raw serialized voxel data suffices.

3. What sort of partitioning/culling methods can apply? Octree/Frustum, Occlusion Culling?

This is sort of orthogonal to voxel/marching cubes, but you can use any method. It depends on what you want really/application domain. For example, in medical applications, you can't really use occlusion culling, because the volumes' color may need to be alpha blended with volumes occluding them. Usually however, if you have multiple volumes, at a minimum, you would do view frustum culling.

4. What sort of LOD techniques work well? (This could kind of apply to question 2 I guess)
5. Know of any simple examples I can examine?

PolyVox is a very good library that is used to work with voxel data. There's a lot of information on all of your above questions on the forums there.


C4 engine is another:


In Topic: I just realized the classic lighting model makes no physical sense

20 February 2011 - 09:40 PM

Any approximation which looks convincing for the materials at hand, is good enough. There doesn't even have to be a physical basis for it.

For example, this rather old demo:


Just uses an N.V term for the lighting and some other neat tricks.

I also would recommend slapping on some fresnel term (or some equivalent of it thereof) in any lighting model that you end up using. In my experience you can simulate a lot of materials by just tweaking the fresnel terms. (For example, rim lighting for a skin shader)

In Topic: Theory to a Good Renderer

30 January 2011 - 07:46 AM

Scene management, transformation hierarchies, etc are something that lie outside the scope of a renderer, in terms of a design. Like a wrapper.

I think for your renderer, you should try to emulate the capabilities of OpenGL first (however minimal)

You can then add a layer on top of your renderer that encapsulates logical/spatial grouping, scene management, etc and forwards draw calls to your renderer.