Tim Moore

> Hello,
> A couple of weeks ago I was asked for a sample of an effects file that
> uses my
> proposed changes to the property system; here it is. The syntax differs
> from
> current property system syntax in two ways: it uses vector types for some
> properties, and some properties can have a variance="dynamic" attribute
> that
> indicates that a parameter can be animated and that graphics state that
> depends on it may need to be updated.
> 
> Many people seem unconvinced by my arguments for new property types.
> That's fine;
> I'm still convinced that they are desirable :) One implementation reason
> that I
> would like to treat values like colors as vectors is that the underlying
> OSG type
> is a vector, so if the components are individual properties that can be
> written
> individually, the implementation choices for updating the OSG state are
> unattractive:
> 
> 1) Write the full vector every time a component is changed. This means
> potentially 4
> times the memory traffic to change a color, and leaves the values stored
> in OSG in
> an inconsistent state for a time.
> 
> 2) Update all effects with dynamic components every frame. We have a lot
> of material
> animations, and their management is currently eats a lot of time in the
> update phase,
> so I'd like to avoid this. On the other hand, we may be updating most
> animations
> every frame anyway.
> 
> 3) Record which effects have been changed, then update their OSG state.
> Complicated
> bookkeeping...
> 
> If people really don't like the effects syntax, I might be willing to hold
> my nose
> and use the existing property implementation. I'm also not committed to
> having the
> effects properties be of class SGPropertyNode; they might be a subtype.
> 
> <?xml version="1.0" encoding="utf-8">
> <!--
>    An effect consists of parameters and techniques. The "parameters"
>    section of an effect is a tree of values that describe, abstractly,
>    the graphical appearence of objects that use the effect. Techniques
>    refer to these parameters and use them to set OpenGL state or to
>    set parameters for shader programs. Parameters can be declared to
>    have a dynamic variance, which means that if their value is changed
>    the corresponding value in the technique will be changed too.
> 
>    A technique can contain a predicate that describes the OpenGL
>    functionality required to support the technique. The first
>    technique with a valid predicate in the list of techniques is used
>    to set up the graphics state of the effect. A technique with no
>    predicate is always assumed to be valid.
> 
>    A technique can consist of several passes, which are run in
>    sequence.
> 
>    One feature not fully illustrated in the sample below is that
>    effects can inherit from each other. The parent effect is listed in
>    the "inherits-from" form. The child effect's property tree is
>    overlaid over that of the parent. This means that effects that
>    inherit from the example "default effect" below could be very
>    short, listing just new parameters and adding nothing to the
>    techniques section; alternatively, a technique could be altered or
>    customized in a child, listing (for example) a different shader
>    program. Material animations will be implemented by creating a new
>    effect that inherits from one in a model, overriding the parameters
>    that will be animated.
> -->
> <PropertyList>
>   <effect>
>     <name>default-effect</name>
>     <!-- <inherits-from>another-effect</inherits-from> -->
>     <parameters>
>       <material>
>         <ambient type="vec4d">
>           0.0 0.0 0.0 1.0
>         </ambient>
>         <diffuse type="vec4d">
>           .5 .5 .5 1.0
>         </diffuse>
>         <specular type="vec4d">
>           0.3 0.3 0.3 1.0
>         </specular>
>         <emissive type="vec4d" variance="dynamic">
>           0.0 0.0 0.0 1.0
>         </emissive>
>         <shininess>1.2</shininess>
>       </material>
>       <texture0>
>         <texture2d>
>           <image>city.png</image>
>           <filter>linear-mipmap-linear</filter>
>           <!-- also repeat -->
>           <wrap-s>clamp</wrap-s>
>           <wrap-t>clamp-to-edge</wrap-t>
>           <!--
>              <wrap-r>clamp-to-border</wrap-r>
>              -->
>           <!-- float, signed-integer, integer -->
>           <internal-format>normalized</internal-format>
>         </texture2d>
>       </texture0>
>       <texture1>
>         <texture2d>
>           <image>detail.png</image>
>           <filter>linear-mipmap-linear</filter>
>           <!-- also repeat -->
>           <wrap-s>clamp</wrap-s>
>           <wrap-t>clamp-to-edge</wrap-t>
>           <!--
>              <wrap-r>clamp-to-border</wrap-r>
>              -->
>           <!-- float, signed-integer, integer -->
>           <internal-format>normalized</internal-format>
>         </texture2d>
>       </texture1>
>       <bump-height type="double">.05</bump-height>
>       <pattern-rotation type="vec4d">0 0 1 1.5708</pattern-rotation>
>     </parameters>
>     <technique>
>       <predicate>
>         <or>
>           <less-equal>
>             <value>2.0</value>
>             <glversion/>
>           </less-equal>
>           <and>
>             <extension-supported>GL_ARB_shader_objects</extension-
> supported>
>             <extension-supported>GL_ARB_shading_language_100</extension-
> supported>
>             <extension-supported>GL_ARB_vertex_shader</extension-
> supported>
>             <extension-supported>GL_ARB_fragment_shader</extension-
> supported>
>           </and>
>         </or>
>       </predicate>
>       <pass>
>         <lighting>true</lighting>
>         <material>
>           <ambient><use>material/ambient</use></ambient>
>           <diffuse><use>material/diffuse</use></diffuse>
>           <specular><use>material/specular</use></specular>
>           <shininess><use>material/shininess</use></shininess>
>         </material>
>         <texture-unit>
>           <texture2d><use>texture0/texture2d</use></texture2d>
>         </texture-unit>
>         <texture-unit>
>           <texture2d><use>texture1/texture2d</use></texture2d>
>         </texture-unit>
>         <shader-program>
>           <uniform>
>             <name>bumpHeight</name>
>             <type>float</type>
>             <use>bump-height</use>
>           </uniform>
>           <uniform>
>             <name>patternRotation</name>
>             <type>vec4d</type>
>             <use>pattern-rotation</use>
>           </uniform>
>           <vertex-shader>
>             "Shaders/util.vert"
>           </vertex-shader>
>           <vertex-shader>
>             "Shaders/foo.vert"
>           </vertex-shader>
>           <fragment-shader>
>             "Shaders/foo.frag"
>           </fragment-shader>
>         </shader-program>
>       </pass>
>     </technique>
>     <technique>
>       <pass>
>         <lighting>true</lighting>
>         <material>
>           <ambient><use>material/ambient</use></ambient>
>           <diffuse><use>material/diffuse</use></diffuse>
>           <specular><use>material/specular</use></specular>
>         </material>
>         <texture-unit>
>           <texture2d><use>texture0/texture2d</use></texture2d>
>         </texture-unit>
>       </pass>
>     </technique>
>   </effect>
> </PropertyList>
> 
Wow! Complicated or what? I can live with the colour stuff - just. But I
think there's stuff there which will for ever catch me out:

<less-equal>? We use <less-than-equals> everywhere else. Unless this has the
sense "some animals are more equal than others"

<texture0>, <texture1>. I would expect <texture>, <texture>. Unless these
tags have totally different meaning, in which case they should be named
differently.

<ambient><use>material/ambient</use></ambient> ? I would expect, perhaps
wrongly:

<material>
        <use>
           <ambient>material/ambient</ambient>
           <diffuse><use>material/diffuse></diffuse>
           <specular><use>material/specular</specular>
        <use>
</material>

I think you would have to be a very dedicated developer to wade into this.
Nevertheless, the access to shader programs looks very worthwhile. In fact I
would accept (almost) anything to get that facility on board.

Vivian







------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to