As seen in Creator, a light point has the following attributes :

1) Light Point Type : String w/Delta, String w/Count, String w/Delta and Count

2) Number of Lights : associated to the fltRepCnt attribute

3) Delta

4) Draw Order : associated to the fltLpDrawOrder attribute

How can I set or get the Light Point Type and Delta attributes ? Some attributes defined in fltcode.h could potentially be used but they are not defined as being members of fltLightPoint.

Also, is the global shape (straight, curve or spiral) uniquely defined using the fltMatrix part of the fltLightPoint structure ? I am using Openflight API 4.2.0 version.

By the way, the fltLpRandomizeIntensity and fltLpQuality fields are tagged as mgbool (4) while they should in fact be int (4). It has been like this for several years.

Thank you in advance !

How can I set or get the Light Point Type and Delta attributes ? Some attributes defined in fltcode.h could potentially be used but they are not defined as being members of fltLightPoint.

First, the short answer... you can "get" additional light point attributes (if they are present) but you cannot "set" them. I'll describe the "get" part and show you how to do this at the end of this post. The limitation on the "set" part will become more clear as you read the details presented in this next part...

Ok, some grubby details. Skip to the end if you just want to know how to "get" this data.

Light Point node attributes are separated into two parts. The first part (the stuff you see publicly in the OpenFlight Data Dictionary) is the part that defines the light point itself and is meant to include everything necessary for a runtime to "render" the light point. The second part (the stuff you might see in the header file but is not generally public in the OpenFlight Data Dictionary) is called the "modeling data" and is a separate (optional) record that describes how the light point was created. Again this record is optional and is not strictly needed for rendering of the light point. If the light point was created in Creator this information will be present. If the light point was created by a 3rd party app/tool, more than likely this modeling data will not be present.

Ok, the public part of the Light Point node is pretty self explanatory. You can see the attributes available in the fltLightPoint record. Light "strings" will have fltRepCnt and fltMatrix values. All others (including random and grid types) make individual vertices on light point nodes for each "random" or "grid" point (there is no simple fltRepCnt and fltMatrix combination possible to describe these).

The modeling data part of the Light Point node is (as you've discovered) semi-private. You can "get" to it and I'll show you how below, but you cannot "set" it. You cannot "set" it because only Creator (not the API) knows how to "build" the light string using this modeling data as input. For example, you might expect that if you created a light point using the OpenFlight API and set up all the modeling data attributes that the API would magically create your light point node with the proper fltRepCnt and fltMatrix attributes (for strings, spirals and curves) and generate the separate points (for random and grid types). While that would be nice, the OpenFlight API does not have this capability, only Creator does.

This is the reason that this modeling data is semi-private.

Ok the good news is that you can "get" the modeling data if it is present. Remember if the light point was not created with Creator, this data won't necessarily be there!

The modeling data of a Light Point is stored as an ancillary record on the light point node. The record code for this is fltLpModel. To get this record, use mgGetAttRec with record code fltLpModel. Here is how you would do this in OpenFlight script (similar in C btw):

modelData = mgGetAttRec(rec, fltLpModel, None)

The following lists the fields in the fltLpModel record (and sizes and comments):

fltLpModel:

fltLpLightType int(4):

0 = String w/Delta

1 = String w/Count

2 = String w/Count and Delta

3 = Light Points

4 = Random Rectangle

5 = Random Circle

6 = Light Grid

7 = Random Polygon

fltLpStringType int(4):

0 = Straight

1 = Curve

2 = Sprial

fltLpDelta double(8)

fltLpCount int(4)

fltLpDensityPerKM int(4)

fltLpRandomDelta float(4)

fltLpDirection fltVector

fltLpColor unsigned int(4)

fltLpPercent float(4)

You "get" these using mgGetAttList on the fltLpModel record you got from mgGetAttRec above. You should not "set" these. If you do, the API won't do what you probably want and you may leave your light point in a strange state that Creator won't understand the next time you open it there.

Here is a sample of how you might put this all together in OpenFlight script (again C is similar):

modelData = mgGetAttRec(rec, fltLpModel, None)
n,code,lightType = mgGetAttList(modelData, fltLpLightType)
n,code,stringType = mgGetAttList(modelData, fltLpStringType)
n,code,count = mgGetAttList(modelData, fltLpCount)
n,code,delta = mgGetAttList(modelData, fltLpDelta)
print "fltLpLightType",lightType
print "fltLpStringType",stringType
print "fltLpCount",count
print "fltLpDelta",delta

I hope this information helps.

Also, is the global shape (straight, curve or spiral) uniquely defined using the fltMatrix part of the fltLightPoint structure ? I am using Openflight API 4.2.0 version.

Yes, when you build these types in Creator, the app calculates and sets the proper values on fltRepCnt and fltMatrix to make strings, spirals and curves. As I suggested in my last response, random and grid types makes light point type with multiple vertices (each vertex for a different random/grid point).

By the way, the fltLpRandomizeIntensity and fltLpQuality fields are tagged as mgbool (4) while they should in fact be int (4). It has been like this for several years.

Thanks for the heads up! Since both are 4 byte values, this should not have been a show stopper for you - but certainly we should correct the docs :red:.

Excellent explanation Steve !

Doing a few tests of my own, I figured out that, depending on the transformation(s) applied to the lightpoint node, I am able to derive what shape was used. If a "rotate about point" matrix is present then by using the vertex XYZ coordinates along with the fltXmRotateCenter, fltXmRotateAngle (and also the fltXmRotateAxis), I can compute what the delta value is (trigonometry). In the case of a regular translate matrix, it is even easier. I am not using the general matrix to do that. This is all without having to access the modeling part of the node. But to determine the "Light Point Type", I have no other choice but to use mgGetAttRec() !

Thank you again Steve !

P.S.: Aside from fltLpModel, which other record types are available which are not covered by the API ?

One last question that just came to me regarding light "strings".

Let say using the API, I want to convert a light "string" with a replication count of N lights into individual light points, do I simply translate the single vertex to the origin, successively apply the fltMatrix (general matrix) N-1 times and then translate back all the points ? This is the back and forth translation part that I am not too sure about.

Thanks again ! :-)

P.S.: Aside from fltLpModel, which other record types are available which are not covered by the API ?

There are very many "internal" attributes on individual nodes that are not publicly documented in the API. For the most part, when something is not included in the docs that just means it is generally not useful or has a different public representation. If I think of any that I might think you could use, I'll blast them out here. Better to do that I believe than try to enumerate these "internal" fields and try to explain them ;-)

One last question that just came to me regarding light “strings”.

Let say using the API, I want to convert a light “string” with a replication count of N lights into individual light points, do I simply translate the single vertex to the origin, successively apply the fltMatrix (general matrix) N-1 times and then translate back all the points ? This is the back and forth translation part that I am not too sure about.

No, it is simpler than that. When a light point node is a light string, curve or spiral, the position of the vertex under the light point is the position of the first light in the string/curve/spiral. Call this light point 0 and call its position p0. Then for N from 1 to fltRepCnt, the position of light point N is p(N-1) * fltMatrix.

So the position of the 2nd light point in the string is the position of the vertex * fltMatrix. The position of the 3rd light point is the position of the 2nd light point * fltMatrix.

This strategy makes "translating" a light string very simple. Just reposition the first vertex. Since all the other points of the string are relative to this point, they all "follow" nicely.

When a light point has fltRepCnt of Y, the light string has Y+1 lights.

Here is an OpenFlight script snippet that prints out the positions of the light points in a light string/spiral/curve. To use this, pass the function a light point node. It shows how the positions of each point of the light string is calculated.

def PrintLightPointPositions(rec):
    # make a variable to hold an mgcoord3d
    c = mgcoord3d()
    # get the vertex of the light point node
    vtx = mgGetChild(rec)
    # get the position of the first light point
    b,c.x,c.y,c.z = mgGetVtxCoord(vtx)
    # and its fltMatrix and fltRepCnt
    b,mat = mgGetMatrix(rec, fltMatrix)
    n,code,repCnt = mgGetAttList(rec, fltRepCnt)
    # position of vertex is first light point
    print "light point 0",c.x,c.y,c.z
    for i in range(1,repCnt+1):
        # then position of "next" point
        # is position of "previous" point
        # transformed by fltMatrix
        c = mgCoord3dTransform(mat, c)
        print "light point",i,c.x,c.y,c.z

Hi Steve,

Forget what I just said about translating the single vertex under the light point. On the other end, when I said successively applying the matrix N-1 times, what you just explained is exactly what I meant.

Great exchanging with you ! ;-)