[News] Ogre 1.11 User Survey Results

News, announcements and important global threads from the Ogre3D Team.
Post Reply

Posts: 158
Joined: Wed Feb 03, 2016 2:24 am
x 3

Re: [News] Ogre 1.11 User Survey Results

Post by hyyou » Thu Apr 11, 2019 4:23 am

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

    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;
1 x

OGRE Team Member
OGRE Team Member
Posts: 750
Joined: Sun Mar 30, 2014 2:51 pm
x 116

Re: [News] Ogre 1.11 User Survey Results

Post by paroj » Thu Apr 11, 2019 11:33 am

hyyou wrote:
Thu Apr 11, 2019 4:23 am

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..
2 x

User avatar
Posts: 309
Joined: Fri Apr 09, 2010 5:28 am
Location: Florida
x 102

Re: [News] Ogre 1.11 User Survey Results

Post by EricB » Fri Apr 12, 2019 1:34 am

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.
2 x

Post Reply