Start a new topic

Setting fltPolyPrimeColor

Original Post by: notsofast Tue Sep 2 03:52:36 2014


When I set the value of fltPolyPrimeColor like this:

mgSetAttList(polyRec, fltPolyPrimeColor,0, fltPolyPrimeIntensity,1.0)

then save the .flt file and look at it in Creator, I see

Creator Primary Color

Index: 127 Name: 127 Intensity: 1.000000


When I set it like this:

mgSetAttList(polyRec, fltPolyPrimeColor,127, fltPolyPrimeIntensity,1.0)

then save the .flt file and look at it in Creator, I see

Creator Primary Color

Index: 16383 Name: 16383 Intensity: 1.000000


I am led to believe by another post that this is correct behavior, but I can't make sense out of it. Can anyone explain the mapping from OpenFlight API value to the displayed value and the reasoning behind it?


Original Post by: SteveThompson Tue Sep 2 16:20:04 2014


There is a FAQ in the OpenFlight API Reference that talks about this. Have a look and if you still have questions, let us know.


The specific FAQ is titled:

What is the difference between Color Index/Intensity and Creator Color Index attributes?

Original Post by: notsofast Tue Sep 2 18:15:46 2014


Thanks for pointing me to the FAQ. That explains it.


First, I find it surprising that the color information is stored redundantly in OpenFlight, as the separate Index/Intensity pair and combined as the Creator Color.


Second, I will suggest a Creator UI enhancement. I do understand that Creator users may not need to know how the field values map to OpenFlight, but at least in this case I would find it less confusing if the Color Panel field names (Index, Intensity) more clearly indicated whether they corresponded directly to OpenFlight field values or not. My understanding is that Intensity directly maps to fltPolyPrimeIntensity, but Index maps to fltPolyCreatorPrimeColor and not to fltPolyPrimeColor. This topic is probably a discussion for the Creator forum.


Third, not clear in the API docs: the semantics of setting the fields. If I set fltPolyPrimeColor and fltPolyPrimeIntensity, is fltPolyCreatorPrimeColor automatically updated? (It is.) What happens if I set them in the same mgSetAttList() call to values that disagree?

Original Post by: SteveThompson Tue Sep 2 19:01:30 2014


First, I find it surprising that the color information is stored redundantly in OpenFlight, as the separate Index/Intensity pair and combined as the Creator Color.

Sorry if the FAQ suggests this, but that is not the case. The color information in the scene graph is only stored one time as a single color index (the Creator Color Index). In the OpenFlight API you have two "views" of this data. You can access this data (get/set) by API Index/Intensity or by Creator Color Index. The getters and setters of this data (for the different "views") sort it all out to maintain a single color value on the geometry in the scene. Note that it makes no sense, programmatically, to mix API Intensity and Creator Color Index - this won't work conceptually. You either access the data through API Index/Intensity or through Creator Color Index.


Second, I will suggest a Creator UI enhancement. I do understand that Creator users may not need to know how the field values map to OpenFlight, but at least in this case I would find it less confusing if the Color Panel field names (Index, Intensity) more clearly indicated whether they corresponded directly to OpenFlight field values or not. My understanding is that Intensity directly maps to fltPolyPrimeIntensity, but Index maps to fltPolyCreatorPrimeColor and not to fltPolyPrimeColor. This topic is probably a discussion for the Creator forum.


Admittedly this can be confusing to someone straddling the Creator and OpenFlight API views of Color, so we appreciate your suggestion.


As I suggested above, there is only one single color value on the geometry and that is the Creator Color Index. The OpenFlight API Index/Intensity "view" is purely manufactured in the API to provide a programmatically "simpler" way to access this information - simpler in the sense that you can "shade" your color (adjust the intensity) without having to do the modulo/division math in your code.


Since that is the case, I am not sure "showing" the "manufactured" API color index value to the Creator user is helpful. I agree it would help you (the "programmer") but would it help the "modeler"? Specifically on the Color Palette, the modeler in me wants to see the Creator Color Index not the API Color Index since the Creator Color Index is the value that I expect to see assigned to my faces, meshes, etc. Having the Creator Color Index value here allows me to copy/paste (e.g., text from here to face attribute page). Having the API color index here might muddy the waters for the modelers and could introduce errors. Users might assign the API color index to their geometry and that would be incorrect.


But, your suggestion is thoughtful and worth considering ... so thanks again.


Third, not clear in the API docs: the semantics of setting the fields. If I set fltPolyPrimeColor and fltPolyPrimeIntensity, is fltPolyCreatorPrimeColor automatically updated? (It is.) What happens if I set them in the same mgSetAttList() call to values that disagree?

As I noted above, this is not a problem. Since there is one single color value (Creator Color Index) in the scene graph, no matter how you set it (by API Index/Intensity or Creator Color Index) you are setting one single value. There is no need to keep the "values" in sync as the "values" cannot "disagree" since there is only one value! The API takes care of it for you.

Original Post by: SteveThompson Tue Sep 2 19:22:14 2014


I missed this part of your last question...

What happens if I set them in the same mgSetAttList() call to values that disagree?


Since there is really only one color index value under the hood, assigning both fltPolyCreatorPrimeColor and fltPolyPrimeColor is the same as passing two different values for fltPolyPrimeColor. Clearly, the following (in OpenFlight Script) is ambiguous:


mgSetAttList (poly, fltPolyPrimeColor, 0, fltPolyPrimeColor, 3)


In this code, the API does not define which value will actually be assigned. You might find that the "last" value listed is the one assigned but if you write your code to depend on this, you are asking for trouble and should not.


Following that logic, if you were to do this (as your question asks):

mgSetAttList (poly, fltPolyPrimeColor, 0, fltPolyCreatorPrimeColor, 2345)


The API does not define which value is actually set.


As I suggested in my previous post, you should access the color information using the API Index/Intensity view or the Creator Color Index view. And since there is a single color value under the hood, there is no chance the data can become "out of sync".

Original Post by: notsofast Tue Sep 2 20:10:27 2014


Sorry. I always assumed that the record definitions in the OpenFlight Data Dictionary were the actual structures that get stored in an OpenFlight file. But now that I compare them with the actual OpenFlight Specification document, I see that that is not the case.


Your suggestion to avoid writing code that depends on any unclear API behavior is a good one.

Original Post by: SteveThompson Tue Sep 2 23:16:30 2014


Sorry. I always assumed that the record definitions in the OpenFlight Data Dictionary were the actual structures that get stored in an OpenFlight file. But now that I compare them with the actual OpenFlight Specification document, I see that that is not the case.

It's far worse than that ;-). The OpenFlight Data Dictionary (and the OpenFlight API) are really an abstraction to the "in-memory" scene graph which, in turn, resembles (to different degrees) what is actually written to disk. This layering is important in that it allows the internal in-memory data structures / implementations to change without "breaking" client code written to the "abstraction".


Your suggestion to avoid writing code that depends on any unclear API behavior is a good one.

I hope that is just common sense. Just because an API allows you to do ambiguous things (mgSetAttList does not disallow passing the same field code multiple times) does not mean you should do those things ;-)


Anyway, thanks for your participation on this forum. I am sure others will benefit from our conversation here.

Login to post a comment