Scenario:

"Combine" several FLT files into one by creating a blank 'master' FLT, opening each 'detail' FLT, doing a mgDuplicateToDB on each desired model which copies that model to the 'master'.

Now, the question is...how/what do I use to 'place' the new model in the location I want it to be?

Real-World example would be to create a 'forest' by placing various tree models into a bigger master FLT file.

Do I use fltMatrix? Where is the docs & samples for doing something like this? I have search through the help, but cannot find any specific 'howto'.

Thanks again!

[QUOTE]

“Combine” several FLT files into one by creating a blank ‘master’ FLT, opening each ‘detail’ FLT, doing a mgDuplicateToDB on each desired model which copies that model to the ‘master’.[/QUOTE]

This is one way to do it. Another way is to create external reference (fltXref) nodes in your master file which reference the desired models. This second technique is much more efficient in the case where you want hundreds or thousands of the same tree (in different locations or even scaled/rotated independently).

[QUOTE]Now, the question is…how/what do I use to ‘place’ the new model in the location I want it to be?[/QUOTE]You have two choices.

1) You can transform the XYZ of the vertices - this is a bit tedious but may be efficient in some cases and will only work if you mgDuplicateToDb the models. This won't work if you use external references because if you change the fltXref vertices, you'll affect all master files that reference that model.

2) Attach a transformation record to the node you want to 'place'. This is very simple and probably the best option in your situation. In a nutshell you create a transformation record (fltXmTranslate, for example), set its attributes and then simply attach it (mgAttach, mgAppend) to the node you want to 'place'.

Transformations are discussed in the OpenFlight API User's Guide (Volume 1) Chapter 4 and the SDK includes some sample code showing how to do it (see egxform1.c or search for fltXm, there are a few) in the sample app folder.

You can also take a look at this forum post: [URL]support/discussions/topics/511[/URL]. It describes the relationship between transformations and the node's matrix.

Finally, here is a quick sample that scales and translates a node. Using this combination you could populate your forest with multiple instances of the same tree model all with different sizes and positions.

mgrec* scale;
mgrec* translate;

// create the scale transformation
scale = mgNewRec (fltXmScale);

// create the translate transformation
translate = mgNewRec (fltXmTranslate);

// set the parameters of the scale
// scale about the origin
mgSetCoord3d (scale, fltXmScaleCenter, 0.0, 0.0, 0.0);

// scale uniformly by 2
mgSetAttList (scale,
      fltXmScaleX, 2.0,
      fltXmScaleY, 2.0,
      fltXmScaleZ, 2.0,
      MG_NULL);

// set the parameters of the translation
// translate by 10,10
mgSetCoord3d (translate, fltXmTranslateDelta, 10.0, 10.0, 0.0);

// attach the transformations so we scale first, then translate
mgAttach (node, scale);
mgAppend (node, translate);  // note the translate is "appended"

Thanks Steve!

Is there a quick way of burning transformed nodes in place? ie. the API equivalent of "make geometry"?

nvr mnd ... read the last question wrong

Unfortunately there is no quick way that I know to do this. The problem is that the xforms are on the groups/objects above the geometry and they can be nested in other groups/objects that have xforms. Never fear though, there are some functions that assist in this effort.

mgWalk can be passed a MWALK_MATRIXSTACK flag that tells it to keep track of the current matrix stack. You can then ask for the matrx inside of your walk function. Typically you walk to the vertex level, then apply the cumulated matrix to the vertex position. Then in a postcallback function, you can remove the XForms. If you are not starting your walk from the db, then you may want to use mgWalkEx and specify a start matrix.

You have to make sure you know all the implications of what you are doing however. The xforms on the groups affect more than just vertices. They also affect nested DOFs, Replicated nodes like light point strings etc... If you remove xforms above the geometry, you have to be careful.

Hmm. Seems more involved than I thought. It's actually in relation to a method I thought of for solving the question I posted in a new topic : support/discussions/topics/727