Suggestion: Geometric Textures with LODs and some CSG magic
Hello,
Always wanted to see classic Doom and Hexen with more detailed geometry. I didn't like the way it was (re)done in Classic Doom mod for Doom 3. The way I want to offer is Geometric Textures. Nothing really new indeed, but this feature could be implemented in "non-forced" way, so textures could be "made geometric" one by one on demand and free will.
Idea is simple. Make library of so called Geometric Textures (GT), where every such "texture" consists of LODs of height-mapped polygons and additional decorators and may also be animated (like wavy water, slime, etc.). LODs could be static or dynamic (procedurally mixed), depending on GT source format and used algorithms. Of course, advanced vector/pixel shaders could be used to add even more detail and simplify far LODs. It is known that in Doom walls and floors textures often clipped in different ways (depending on sectors shapes), so GT technology should use some CSG tricks to CLIP AND TIE neightbour edges of two (edge) or three (corner) surfaces in two ways (outward variant and inward variant). This will do the trick and give us more detailed geometry in cost of more polygons and some massive pre-processing.
Also I can do most coding work on this feature, if required.
I hope there are people who also want feature like this, so I'll be happy to know your opinions and suggestions.
Thanks.
/EyeGem
Always wanted to see classic Doom and Hexen with more detailed geometry. I didn't like the way it was (re)done in Classic Doom mod for Doom 3. The way I want to offer is Geometric Textures. Nothing really new indeed, but this feature could be implemented in "non-forced" way, so textures could be "made geometric" one by one on demand and free will.
Idea is simple. Make library of so called Geometric Textures (GT), where every such "texture" consists of LODs of height-mapped polygons and additional decorators and may also be animated (like wavy water, slime, etc.). LODs could be static or dynamic (procedurally mixed), depending on GT source format and used algorithms. Of course, advanced vector/pixel shaders could be used to add even more detail and simplify far LODs. It is known that in Doom walls and floors textures often clipped in different ways (depending on sectors shapes), so GT technology should use some CSG tricks to CLIP AND TIE neightbour edges of two (edge) or three (corner) surfaces in two ways (outward variant and inward variant). This will do the trick and give us more detailed geometry in cost of more polygons and some massive pre-processing.
Also I can do most coding work on this feature, if required.
I hope there are people who also want feature like this, so I'll be happy to know your opinions and suggestions.
Thanks.
/EyeGem
Comments
I will say however that imposing CSG on to DOOM might be rather tricky, particularly because map geometry is not always solid or even geometrically "clean". Not to mention the potentially hyper-dynamic nature of sector planes.
Now that we have our new internal BSP and GL node builder, the geometry produced is much cleaner however.
DaniJ, what source version would you recommend to download? Or maybe checkout (SVN)?
I've downloaded source for version 1.7.15. It will take me some time to analyze it.
As you may have seen/heard we are currently in the middle of a massive overhaul of the Doomsday architecture and as of 1.9.0-beta7 we are switching new development to C++ (although this does not include the renderer which will likely remain pretty much as-is until the planned rewrite).
As to the prospect of doing something like this I think you'll run into the following road block:
At present there is no real division between the map representation as used for playsim functions like collision detection and the world which is rendered to the user. In fact, in many cases there is no division at all (e.g., wall segments are drawn directly using the same vertex data).
One of the aims for the next phase of development of the map representation is to decouple the two so that the version of the map used for render need not be the same as that used for playsim functions (though until the renderer rewrite the same dataset will continue to be used for both).
As such you may wish to hold off an implementation until more of the above has been completed/designed and documented.
Is git absolutely required or svn will also work?
Q: Will visual data depend on simulation data (i.e. ready to be updated if simulation data updates) to process Hexen "poly-objects" or will all visual variants (including possible "poly-objects" moves) planned to be pre-computed?
Take for example something deceptively simple like a door opening. As we know, doors in DOOM are in fact the planes of the sector acting as a door and when deciding a move, the playsim does something like "find all surfaces attached to this one; the destination height of the door when open is that of the next surface on the world Y axis". This means that if the surfaces around the door move before the door does, the destination height of the door when open changes also.
As the DOOM engine is "2.5d" this means that two thirds of the map data is already precomputed and inherent in the representation itself (i.e., static/fixed on the X/Z plane). However the planned in-game editor requires updating this on the fly too.
In the 2.0 architecture, polyobjects are treated as fully dynamic objects. During map load we extract the polyobject constructs from the map geometry. So they can be mostly ignored.
Found: doomsday/engine/portable/src/r_world.c - this code seems to work with subsectors for rendering purposes
I've continued on GT technology design and found out it will need that subsectors and surrounding walls fragments should be able to keep cached render data (refs to full meshes, refs to partial full meshes (with some polygons invisible) and, the most interesting part, refs to unique meshes with additional constructed geometry).
I think it will be better for me to develop GT technology in separate project, making it as processing library for meshes and surfaces, until sufficient results will be available. Also will write technology integration documentation to make it clear how it will me meant to be integrated.
Any suggestions?
If you run into any problems with the core geometry let me know and I'll look to see what can be done in the BSP/gl node construction to assist (other than a couple of special cases (i.e., degenerate), subsectors are simple convex polys).
I don't really have any further suggestions right now.
EDIT: I'll move this thread to the "Source Code Sorcery" subforum rather than leave it here in General because it is likely to get a bit heavy going on the "technical stuff"