[News] Ogre 1.11 User Survey Results

News, announcements and important global threads from the Ogre3D Team.
Post Reply
hyyou
Gremlin
Posts: 173
Joined: Wed Feb 03, 2016 2:24 am
x 17
Contact:

Re: [News] Ogre 1.11 User Survey Results

Post by 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
OGRE Team Member
OGRE Team Member
Posts: 1994
Joined: Sun Mar 30, 2014 2:51 pm
x 1074
Contact:

Re: [News] Ogre 1.11 User Survey Results

Post by paroj »

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..
User avatar
EricB
Bronze Sponsor
Bronze Sponsor
Posts: 360
Joined: Fri Apr 09, 2010 5:28 am
Location: Florida
x 213
Contact:

Re: [News] Ogre 1.11 User Survey Results

Post by 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.
Image
paroj
OGRE Team Member
OGRE Team Member
Posts: 1994
Joined: Sun Mar 30, 2014 2:51 pm
x 1074
Contact:

Re: [News] Ogre 1.11 User Survey Results

Post by paroj »

EricB wrote: Fri Apr 12, 2019 1:34 am 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
Post Reply