Renderer improvements

[Komag]

Yeah, we could have a set of "tiles" for a "pathway".

 

There could be tiles such as:

- "straight path"

- "intersection piece"

- "turn piece"

- "edge piece"

- etc (sort of like the land tiles in the game Carcasonne)

 

There could just be two different textures. Then we can build a courtyard area with the tiles, and just plug in which texture we are going to use for our "grass" and which texture for the "path" gravel or whatever.

[OrbWeaver]

There's certainly nothing to stop you from creating some generic dirt mounds or whatever that contain vertex colour information, and then the skin can switch between multiple blending texture pairs, as well as textures which don't use the vertex colour information at all. This was what I was trying to illustrate in the skins tutorial by having one skin which used vertex colours while the rest didn't.

 

Note that you can't switch the blend textures individually: you can switch from a material that blends between [A and B] to a material that blend between [b and C] or [C and D] with a skin, but you can't just switch image A without creating a new material.

[Fidcal]

Some models need adjusting to within inches. I think I adjusted the single curtain model we have twice in Chalice in different positions to precisely fit. Likewise the window model I used a lot in different rooms and at least twice or more I had to adjust its size or not use it at all. Models are generally placed after brushwork. I cannot see mappers adjusting the size of their rooms to fit models - and not all models are created equal as it were.

 

I once looked in a model file and found scale values. I tried changing them but could see no effect. If there were some simple way for mappers to change those it might be useful.

 

Maybe I should take up modelling if only to find out how to rescale then write an idiot's A to Z guide from downloading the program to saving out the rescaled model. But there are at least two types of models and I'm not sure there are freebies for both?

 

As ever, time is the enemy.

[greebo]

You can do LWO and ASE editing in Blender, although it's admittedly a non-trivial task to export a proper LWO from Blender.

[jdude]

This makes me all warm n happy inside

[OrbWeaver]

Vertex blending

 

Support for blending between multiple diffusemaps using vertex colours is now implemented. Maybe this screenshot will better demonstrate the value of vertex colouring than before:

 

[greebo]

Excellent work so far.

 

(Btw, let me know if you need support in any of your endeavours. I'm happy to help when I can.)

[OrbWeaver]

(Btw, let me know if you need support in any of your endeavours. I'm happy to help when I can.)

 

Thanks, much appreciated. It is possible I may at some point need to draw on your experience when attempting to fix projected lights, since it seems that there are a couple of issues relating to both the projective transformation and inappropriate bounding box culling of the light volume, which I believe you have worked with more than I have.

[SneaksieDave]

I can't believe how quickly I've developed a Pavlovian response.

 

When I see this thread get hit, I start drooling.

[jdude]

Vertex blending

 

Support for blending between multiple diffusemaps using vertex colours is now implemented. Maybe this screenshot will better demonstrate the value of vertex colouring than before:

 

 

Okay I'm confused. Did you make this only in DR? No editing material files, no exporting to blender ect?

[Fidcal]

I'm also confused. This is only to do with rendering in Dark Radiant? It's not something we can use in a map? I'm unsure as to its purpose if it is only in DR.

[greebo]

This is a model, as only these can have vertex colours. The vertex colours are then used to blend between two diffuse maps defined in the shader.

 

Primitives (brushes and patches) cannot have vertex colours, that's why you can't define such transitions in DarkRadiant (this cannot be added right now, in case you wonder). You need to get hold of a modeling app to get these effects on your geometry, it is in fact applicable for the D3 engine (see also the "Separation" thread).

 

DarkRadiant's renderer couldn't handle these multi-diffusemap shaders before, so this is a nice step forward.

[OrbWeaver]

What Greebo said. The entire purpose of the DarkRadiant renderer is to provide a preview of what the map will look like, so I will certainly not spend time implementing something which can't be used in the game (except maybe for diagnostic or map-building purposes, such as a full-bright mode).

 

To set up a material like this, you have to (1) create your model in a 3D app with vertex colours that blend from black to white, then (2) set up a material that contains two diffusemap (and bumpmaps if required) stages, one of which has "vertexColor" and the other "inverseVertexColor". The two textures will then be blended based on the black/white vertex colours on the 3D model.

 

It is used in Separation as Greebo mentioned, as well as certain parts of the Doom 3 Hell levels. It is a much better way (IMO) of producing realistic terrain than using multiple patches which always have sharp joins between the textures.

[OrbWeaver]

Cubemap skyboxes

 

Cubemap (static) skyboxes are now working in the renderer.

 

 

This is only for static pre-rendered skyboxes, portal skies will not work (although I don't think even DoomEdit will do this). The skybox material stage must be a cameraCubeMap using a blend mode (blend add or blend blend, not diffusemap etc) and applied to a brush face, but this covers 100% of all skybox usage I have ever heard of.

[greebo]

Excellent, well done.

[New Horizon]

Great stuff Orb! DR preview is becoming more accurate and complete! Thanks.

[SneaksieDave]

What! Wow.

 

 

 

Damn drooling.

[greebo]

@OrbWeaver: I noticed a serious performance impact during the last 20 revisions. In rev4506 it took max. 50 msec to render a cam frame in gathers.map, whereas now it takes over 250 msec on average = slower by a factor of 5.

 

I think this might be due to failed inlining and/or missing return value optimisation in the core transformation routines. I'm currently stepping up the history to see where things became slow.

 

edit: It's revision 4517, methinks. Rev4514 is fine, but 4517 has become painfully slow.

 

edit2: Wrong, it's not 4517. Reverting to 4516 shows that it's been slow before that.

 

edit3: It's starting with 4515. 4514 is fast, 4515 is slow.

[OrbWeaver]

Is this with the lighting renderer or the preview renderer?

 

I know the lighting mode performance is dire (I was seeing visible choppiness in a single square room with two lights and couple of cubes), but I haven't really started addressing performance issues yet. Obviously if there is a major WTF that I have introduced with a recent change I will try to fix it.

[HappyCheeze]

WOW!

 

Awesome work man, that is AMAZING!

[greebo]

Is this with the lighting renderer or the preview renderer?

It's the non-lighting render preview.

 

I know the lighting mode performance is dire (I was seeing visible choppiness in a single square room with two lights and couple of cubes), but I haven't really started addressing performance issues yet. Obviously if there is a major WTF that I have introduced with a recent change I will try to fix it.

Between rev. 4514 and 4515 several files have been changed, to remove that bizarre EnumeratedValue template.

 

I just double-checked: 4514 takes 30 msec., 4515 takes 250 msec., so there is indeed a WTF going on somewhere here. At first I thought it was the frustum calculations, but it seems it's something else. Surely changing the EnumeratedValue to an enum wouldn't cause such an impact?

 

This needs checking - I ruled out that it's just my build (x64), because it's happening on angua's machine (x86) as well. It probably boils down to a fine-grain check of all the changes between those revisions.

[OrbWeaver]

I just double-checked: 4514 takes 30 msec., 4515 takes 250 msec., so there is indeed a WTF going on somewhere here. At first I thought it was the frustum calculations, but it seems it's something else. Surely changing the EnumeratedValue to an enum wouldn't cause such an impact?

 

OK, you've narrowed it down then.

 

First-order random guess: when renaming the c_volumeOutside crap to VOLUME_OUTSIDE, I got one (or more) of them wrong and now stuff isn't being culled that should be. Just a guess though, I'll have to look at the diff.

 

EDIT: It seems I can't check the diff right now because SourceForge has made the jump from just "annoyingly slow" to "absolutely fucking pathetic", and returns nothing after waiting for over two minutes. I will try again tomorrow, but if this doesn't improve I think we should think about switching to Google Code for hosting.

[jdude]

Just a quick question about the static sky render. Will there be an option to enable/disable this quickly without having to go into preferences? I'm thinking for finding leaks it may be hard using the rendered skybox views.

[greebo]

First-order random guess: when renaming the c_volumeOutside crap to VOLUME_OUTSIDE, I got one (or more) of them wrong and now stuff isn't being culled that should be. Just a guess though, I'll have to look at the diff.

Good guess, I actually found a difference in renderer.h. Seems like all nodes are checked against visibility, even if their parent nodes are completely "outside".

[greebo]

Ok, fixed three occurrences of OUTSIDE, where PARTIAL should have been. The render speed is down at 30 msec again.

 

I'll take this as an eye opener what an effective culling algorithm can achieve (and I'm sure there are more effective ways to do that).