Renderer improvements

[OrbWeaver]

This weekend I was able to get blend shaders working in the DarkRadiant renderer, so that add or multiply material stages (such as might be used for water) now appear correctly.

 

Before

 

 

After

 

 

The blend mode is now read from the MTR declaration, as well as the colour modification values (e.g. "red 0.8, green 0.7"), and these are used by the renderer. Colour modifiers only work for blend stages at this time, since I haven't modified the interaction fragment shader to handle vertex colours for diffuse maps; once this is done we should be able to add support for model vertex colouring as well.

[greebo]

Superb - I was happy reading all these SVN commit messages throughout the weekend.

[SneaksieDave]

Ohshit.

 

 

 

 

*crosses fingers that this might be the beginning of renderer overhauling*

[OrbWeaver]

Superb - I was happy reading all these SVN commit messages throughout the weekend.

 

Happy to produce them. It think it must be about 18 months since I have managed to spend an entire weekend working on DR and produce something useful at the end of it.

 

*crosses fingers that this might be the beginning of renderer overhauling*

 

I'd certainly hope that I could address some of the more simple issues; vertex colours are in sight now, sky boxes (static, not portal) are a distinct possibility, foglights are borderline, and shadows are known to be hard because of the refactoring and maths involved. If the only thing that doesn't work in the DR renderer is shadows, I'll be quite happy.

[SneaksieDave]

About the shadows, I was wondering: is it possible to go to an open source shadow-capable engine (e.g. Ogre or Cube or even Quake open source) and steal borrow methods?

 

 

Edit: holy crap the Ogre3D demos on youtube are incredible

[New Horizon]

Great work Orb. Another step for DR toward accurate previews for mappers.

 

We should talk to the guys I mentioned in this thread.

 

http://forums.thedarkmod.com/index.php?showtopic=9041

 

This was the email I received from the lead coder.

 

Hi,

 

ODRadiant is currently in its very early development stages, and since I'm the only programmer in our team at the moment and I have to work on many tools apart from the engine and game code, I'm affraid it will take a long while to finish. In any case, the plan is to port portions of code directly from the OverDose renderer into ODRadiant for the "render mode" stuff. I'm leaving all this for later since I'm currently rewritting parts of our renderer (mostly the shadowing system), but if you're interested in using parts, or all of it for Dark Radiant, then I could share the code with you. I'm still not sure how I will integrate this into ODRadiant, and I don't know how different Dark Radiant is compared to Q3Radiant (which is our base for ODRadiant), so I may not be in the position of giving you the best advise or help right now, but you can count on the code if you're interested.

 

Regarding our DDS compression utility, you can get the full source from our repository over at SourceForge: https://odblur.svn.sourceforge.net/svnroot/odblur

 

If the GPL license is ok for you, then you shouldn't have problems using it.

 

ODCompress does depend on a DDS compression library by ATI themselves, but it is included with our source and seems to work perfectly so far. Be aware that it has a few things that are specific to our project, but it shouldn't be too hard to modify to suit your needs (mainly file system stuff such as game directories and pack file extensions).

 

 

Nicolas Flekenstein

Lead Programmer, Team Blur

http://www.teamblurgames.com

[OrbWeaver]

About the shadows, I was wondering: is it possible to go to an open source shadow-capable engine (e.g. Ogre or Cube or even Quake open source) and steal borrow methods?

 

Don't underestimate the amount of work involved in integrating foreign code into an existing codebase; using something like Ogre is an excellent choice if you are starting from scratch, but getting it to play nice with an extensive existing infrastructure would almost certainly be more difficult than just implementing the shadow code directly.

 

In case you are just talking about looking at the foreign implementations rather than trying to borrow code directly; this is a valid approach, but in this case, I pretty much already understand how stencil shadows are supposed to work, it's just that there are two major tasks involved in implementing them (plus an unspecified number of "unknown unknowns" and minor tasks):

 

1. Stencil shadows require a rendering algorithm that processes each light individually and accumulates the results into a final image; the DarkRadiant renderer is not organised like this, and considerable refactoring is needed to change this.
   
2. Code must be implemented to calculate shadow volumes by extruding an object's silhouette outwards from the light source; this is not particularly complex mathematically but is completely new code that has to be added, rather than just tweaking and modifying existing functions.
   

 

Possibly if/when all the other more minor renderer issues are addressed, it would be interesting to look at the refactoring in (1) and see if is possible to modify the existing renderer to use this structure without necessarily changing anything else; at this point it would be easier to investigate the possibility of a shadowing implementation.

[SneaksieDave]

Yeah I mostly meant the "seeing how" of it; I've tried tiny integrations with my own stuff a time or two (really trivial stuff comparatively) and yes it seems harder than just starting from scratch.

 

This sounds promising:

In any case, the plan is to port portions of code directly from the OverDose renderer into ODRadiant for the "render mode" stuff. I'm leaving all this for later since I'm currently rewritting parts of our renderer (mostly the shadowing system), but if you're interested in using parts, or all of it for Dark Radiant, then I could share the code with you.

[OrbWeaver]

This sounds promising:

 

Yes, if they are using stencil shadows then their silhouetting and shadow-volume calculation code may be useful to us, once the necessary DR infrastructure is in place to make use of it.

[OrbWeaver]

Vertex colours

 

Initial support for vertex colours is in.

 

 

So far, only simple vertex colour modulation is available, you can multiply your diffuse layer by the vertex colours, but blending between two textures is not yet supported. For this I will need to implement multiple-pass interaction shading.

[SneaksieDave]

Coolness. I'm not sure what exactly this is used for to be completely honest. It makes me think of vertex painting maybe? Is this for display or editing, and for models only or patches? Or am I waaay off and really don't know what it's about.

[Komag]

I also have no idea what has been improved or what that screen illustrates!

[SneaksieDave]

Oh, I think I get what it's for, in terms of DR: display only, in renderer mode of models with texture blending, perhaps?

[Komag]

...and now I have no idea what you just said as well!

[SneaksieDave]

Haha okay, my guess: Did you see Separation? His models (the tunnels) use texture blending if I understand correctly. Well, Orb's recent addition is enabling (or on the way to doing so) DR to properly display those texture-blended models. Yeah?

[Komag]

So we can re-texture models and blend the textures on them? That would be good!

[Springheel]

I suspect it's just displaying vertex blending, not actually doing it...that would still have to be done in a modeling program (or I'll be shocked). As far as I know, none of our models use vertex blending at this time.

[Komag]

so basically the fact that DR can now at least display it is a step in the right direction, I see.

[OrbWeaver]

I never thought that a simple screenshot could be so confusing

 

What is implemented is support for the vertexColor and inverseVertexColor stage keywords in material definitions. These keywords allow a material stage to be multiplied by the vertex colours which are included in the model file (after being added by a modelling program, there is no vertex painting in DR).

 

These vertex colours have two purposes. Firstly, they can modulate and darken the texture on a model in particular places, such as to give the impression of dirt or rust. This is illustrated on the second model from the left in the skins tutorial:

 

http://forums.thedarkmod.com/index.php?s=&am...ost&p=52511

 

Secondly, by using two diffuse/bumpmap stages, once of which has vertexColor and the other inverseVertexColor, it is possible to blend between two textures on the same model by using full-black to full-white vertex colours. This latter function is not yet implemented in the DR renderer, since currently only a single diffuse/bump/specular triplet can be rendered on a model.

[Fidcal]

Going off-topic I know but can texture tiling be used on models? And if so, can't a variety of non-solid, flat panel models be made using vertex blending that might be resized using the rotation hack and placed against walls like decals? And yes, I don't know what I'm talking about.

[OrbWeaver]

Going off-topic I know but can texture tiling be used on models?

 

Yes.

 

And if so, can't a variety of non-solid, flat panel models be made using vertex blending that might be resized using the rotation hack and placed against walls like decals?

 

I don't see why not, but I'm not really sure what you are aiming for here.

[Fidcal]

Erm... maybe I mean texture blending - but as I understand it we can't do it on brushes. If model panels could be used to get the same effect on flat surfaces at least then it might be of use?

[Flanders]

For an ase model you should look for these in the material list (just open it with a text editor).

 

*UVW_U_TILING 1.0000

*UVW_V_TILING 1.0000

 

change the values to change the texture tiling. I don't know how this would work for lwo models. Opening them in a text editor gives me only nonsense.

 

I think I understand what you mean, there might be a value for such flat wall panels. But they wouldn't be flexible and you can't change the vertex pattern in DR. Learning just a little Blender can give you much better results.

[SneaksieDave]

I've been trying to think of something along the same lines (if I understand you correctly). Standard generic panels or columns or mounds or whatever other useful shapes, could have blending coords defined within them, and then we tweak the materials to change the blend constituents. Voila, simple blended building pieces. Depending on how easy it is to modify them, they could have generic position of the blends, or anything the user wants. It'd be great to ship with such a set of "digital legos".

[Fidcal]

Yes, exactly. One problem is that the specular map does not resize but I find many models resize OK if you make then non-solid with a nodraw solid core (we have a range of collision sound types.)