[News] Ogre 1.11 User Survey Results

[paroj]

https://www.ogre3d.org/2019/04/02/ogre- ... ey-results

[hyyou]

Hi! Thank for your hard work, paroj.

I was a Ogre 2.1 user, not Ogre 1.1's (not one of the voters neither), but I feel like my opinion is still relevant.
After I read the article, I felt like a cat stepped on its tail while reading this :-

Originally I wanted to deprecate/ remove the HLMS component from 1.12, but seeing these results I kept it. However I keep wondering why/ how you are using it? It does not give you much over plain #ifdef preprocessor directives in Ogre1. I would be glad if someone could report on their usage in the Forums

1. There are a block of data "vertex shader->fragment shader"
I used it like :-

Code: Select all

@piece(MY_VERTEX_TO_FRAG)
block
{
    vec3 surface_worldPosition_frag;//
    vec3 surface_viewWorldPosition_frag;//view coordinate
    vec3 normal_frag; //note: view-world coordinate
    vec3 tangent_frag; //note: view-world coordinate
    vec3 binormal_frag; //note: view-world coordinate
    ...
}

With this, every time I edited this block, I don't have to copy-paste it to both vertex & fragment shader.

2. I can split a certain block (e.g. output struct format or function) into another file. It keeps my shader short. It is a minor advantage.
3. I don't know if I am the only one, but I love the foreach so much. It could be replaced by array, but I prefer this way.

@foreach( amountOfTexture_num, n )
vec4 uvManipulator@n = entity.uvManipulator@n;

[paroj]

After I read the article, I felt like a cat stepped on its tail while reading this :-

Thanks for the feedback

However @piece statements can be easily replaced by #includes. Those only have a per-file granularity, but actually I think thats an advantage. See the following for an #include based shader system in action:
https://github.com/mrdoob/three.js/blob ... rt.glsl.js

@foreach is the only statement that cannot be replicated with a preprocessor. Yet I wonder if this is enough to warrant maintaining the HLMS..

[EricB]

I'm not using HLMS, and I am barely using RTSS in 1.7 for a reflection cube map (I think). (I have disabled my RTSS in 1.11, as it did not work properly with my 1.7 code).

Assuming I was able to fund a remake of my artwork, I would go with HLMS if Spooky Boo's HLMSEditor works for 1.11+. Why? I can simply hand it off to my artist who understands all this material stuff, it'll look pretty and just work (assuming it loads properly into 1.11...).

RTSS and by extension Ogre 1.x needs a good material editor. I don't understand what half these attributes do. I don't know if my stuff is set up correctly and what results should I expect. Looking at the RTSS documentation, it looks like it's just a big explanation of a shader generation. It's not very helpful for non-artist, non-shader writers.

[paroj]

Looking at the RTSS documentation, it looks like it's just a big explanation of a shader generation. It's not very helpful for non-artist, non-shader writers.

thats a valid point. I restructed the RTSS docs to target non-shader writers first:
https://codedocs.xyz/OGRECave/ogre/rtss.html