Horde3D

Hi all,

I've been enjoying learning / playing with Horde3D over the last few weeks. I have a quick question about setting GLSL preprocessor defines.

I know Horde3D provides a way to set boolean preprocessor defines as part of its ubershader system. For instance, adding <ShaderFlag name="_F01_Skinning" /> to the material.xml will set #define _F01_Skinning in the material's shader.

Is there a way to set non-boolean preprocessor definitions this way? I have a shader with a loop, and I'd like the number of iterations to be changeable:


I believe could use a Uniform for this purpose (and set its value using <SetUniform ...> in the pipeline.xml or <Uniform ...> in the material.xml) but this eliminates the compiler's ability to unroll the loop at compile-time.

For me, it would be especially useful if I could set/change the preprocessor values in the pipeline.xml file for each DrawGeometry/DrawQuad call. Failing that, maybe they could be set in the Context? Something like:

...but I'll leave the heavy software engineering up the experts

Thanks for any ideas,
Spacecookies

That's currently not possible. What you can do instead is to create various sections where you define different iteration defines and enable them by using the _XX_ flag system. But obviously that would be some kind of hack.

Alternatively to what Volker suggested, you could set a common header for all shaders using h3dSetShaderPreambles. This is actually meant for global data like platform defines, however, if you make sure that the define does not cause issues in other shaders, it is an option.

Yeah, I also thought about using/abusing the _XX_ flag system for this. I'm not sure how I could turn the flags on/off in the pipeline.xml though. It's only setup to be done from the material.xml file I think. It would probably require more hacking than I'm willing to do at this point.

I'll look into the h3dSetShaderPreambles approach. A quick look at the docstring says, "The preamble is used when a shader is compiled, so changing it will not affect any shaders that are already compiled." so I think this approach may not work for my purpose, as I'd really like to change the value between draw calls.

For fun I decided just to try using a Uniform for this to see how the performance is without loop unrolling - maybe it's not that bad! I've run into some troubles here too though... The material system in Horde3D seems setup to only handle float types. The documentation (see "FX Section") just describes float and float4 types. So I'm forced into using a float type to check my loop iterations (which works +/-1 iteration , but it's just not ideal).

The real problem is that I can't seem to override the value specified in the material.xml file: with the value specified in the pipeline.xml file: I've stepped through the Horde3D code with a debugger and everything seems to go just fine. I can see the material resource's uniforms being set with the proper "pipeline" values in Renderer::render(). So I'm not sure where it's going wrong. I'll investigate more later. Any thoughts about where to look are appreciated!

Thanks,
Spacecookies

In case anyone's interested, I found the problem I was having with setting the Uniform values. In the scene.xml file for the model/mesh I was specifying the material like this: but in the pipeline.xml file I was specifying the material like this: (note the subtle difference in the material strings!)

So it seems like they must be identical (even if the two would ultimately resolve to the same file in the filesystem) for Horde3D to actually treat them as being the same material. I didn't look to see how this all works internally, but it would be nice if this (at least) threw an error when the material in <SetUniform> doesn't map to any existing material.

Ciao for now!
Spacecookies

The material is referenced by its name not the file path. Actually the material name is only interpreted as a file name by the utility library's function h3dutLoadResourcesFromDisk, otherwise it could be anything. So a mapping of models/cube/cube.material.xml to ./models/cube/cube.material.xml or vice versa would be against Horde3D's philosophy of having no direct relationship between resource names and the file system.

The reason why you won't get an error is because the material for the mesh and the SetUniform node in the pipeline both use a valid material resource. It points to the same file (as mentioned above, that's something Horde3D does not care about) but to different instances within Horde3D and that's why it does not work the way you thought it should.