Heretic

Members
  • Content count

    36
  • Joined

  • Last visited

Community Reputation

122 Neutral

About Heretic

  • Rank
    Member
  1. OpenGL 3D object

    you may take a look at nvidia's scenegraph, they even have a demo of such a car :) http://developer.nvidia.com/object/nvsg_home.html
  2. [web] PHP

    Well, I can't say too much about PHP except for it's extremely ugly . Alternatives ? I'm using Spyce, a Python based server-side scripting language. It's just like PHP but instead of a crippled C++ syntax, it uses the Python language directly. Waiting for 'D Server Pages' though...
  3. New easy to read C language

    LOL @ ppl's fun detectors :>
  4. chunk lod + texture splatting

    you may render the terrain geometry in any order you want with depth test set to EQUAL
  5. I don't think this technique would be very applicable. To voxelize geometry, you'd have to have a perfectly manifold mesh and build a solid-leaf BSP tree with it. Unfortunately, that's not the kind of geometry that artists tend to produce. And even if you forced your artists to do so, you'd already have the right representation to do it all using polygons only. Voxelixing would only worsen the entire quality. Possibly voxels could be used for some simulations, but I'd rather see them in fluid and alike objects, not hard, rough objects that the scene is often composed of. For that example of a bridge it would be more applicable to have a normal polygonal model and add some physics information to it, like where the main construction joints lie, so you could perform physics simulations on it. The VB talk is about carving normal geometry with CSG. You cannot perform CSG on static vertex buffers, so you have to regenerate those. The operation of 'compiling' a static VB takes some time, so Etnu has a technique to use dynamic vertex buffers whilst the upadates to the geometry are performed and 2, 3 frames longer in the case of a massive geometry modification and then convert it to a static vertex buffer to have it render fast. The memory problem could probably be remedied by performing a simple Lod on the output, just like S. Melax does, but also on the surrounding geometry so that you can cut off some polies in one place to add them elsewhere. The OCtree is basically an optimization technique. Let's say you fire your bazooka somewhere. The rocket hits the wall and you want to know what geometry will have to be touched. You can check it using OCTree in order to accelerate the geometrical query on the dataset. Just my view, you mileage may vary ;) Probably one of the most interesting tasks in destructible environments would be to update your radiosity :] You could e.g. put lots of dust everywhere for a few seconds and in the meantime use photon tracing and calculate the lighting over time if ya had a huge hole in a wall between dark and lit rooms... This could be a killer.