Hi there,Is it possible to use variables for looping in XML? I'm building a fence, and rather than build the whole fence, I built a small part as a library object (in GMAX) and I was placing it in sections using the BiasXYZ offset. I am using this method since it allows very accurate placement which permits me to line up the fence without any visible flaws.This is working out well, but calculating the offset gets to be a chore. It would be better to use a For/Next style loop and create variables that could be used in th BiasXYZ section.- Martin

Hi Martin.I don't believe the FS9 XML schema allows for looping at all. :(You could write a simple program in basic, delphi, or java to create the looping, and produce the xml code.... but unless the fence is huge, you're better off coding it by hand.Dick

That's pretty much what I suspected. I think I'll compromise by creating larger fence parts so it'll be less work.- Martin

Martin,If you are going to build your fence for a particular scene and you are using gMax, have a look at the Array commands. You can more or less build one section of fence then string it out over a distance. You can also make a spline path and array it along the spline so it could vary in elevation as well as direction. Works pretty good if you just build one post and two rails (26 polys for a 3d split rail fence) then you just have to move the ends of the rails opposite the post up or down to fit the next post. Once you have it the way you want it, collapse it to a single object if you want by attaching the arrayed objects to the original.Lou

I didn't know you could array along a spline! Hmmmmmm....thanks for the concept.Bob Bernstein

Ok, that's a good idea. I'm not incredibly proficient at GMAX, so I wasn't even aware of arrays, but I'll keep it in mind to experiment with this in the future. Has anyone tried this method before? Is this method as optimized as using library objects (trying to keep the framerates high). In the meantime, I've already got all my fence posts planted - there weren't many to do anyway.- Martin

It would seem to my feeble brain that using an array within Gmax would produce one large fence object for export. Don't get me wrong, it sounds like a great trick for making a fence (I didn't know you could use splines w/arrays either -- good tip!). I can't see how it'd result in a performance boost though, as you'd still end up exporting one huge fence object w/one refpoint, which would create its own set of problems. Using the BiasXYZ in the XML would actually produce an optimized fence w/many segments with their own refpoints and thus better perfomance optimization, yes? Or am I once again completely befuddled ;-)?thanks,

Doing it in GMax indeed gives one big object.But in the new XML code you can no longer give the distance anymore for the RefPoint, so it is rather big for most objects anyway. Therefore I think it has less influence if you place them in a lot of RefPoints. But maybe we should try to test this first :D.

But is there still a benefit to using library objects for an object which needs to be repeated over and over? If I am planting 100 trees, is it not better to plant one "library" tree 100 times, rather than a single "clump" of 100 trees? I can use the same analogy for my fence, which is really just a small section repeated many times. In the "old way" of scenery design, this would kill framerates when I tried to make it but copying an .api macro over and over, but with the new XML style maybe it doesn't matter if you place many small macros or one big macro (in terms of framrates). If so, then this would make some aspects of scenery design easier.- Martin

Can't really answer this, as I have not tested it.But with the XML code any object you place is a library object, so the difference between placing a library object or placing a normal object is no longer there.What the difference between 1 big object and a lot of repeated objects is I can not say. I expect that placing it as a library is still better.And of course libraries also have other advantages, for example when you change the object you only have to do it once and everywhere you placed it will follow automatically.

Guys,Why not have the best of both? Put your objects in a library then array the attach points in the scene. You couldn't see how the array actually looks in gMax other than for the location of the objects but that should keep the scene file smaller. Could this not work?Lou

Good thought, Lou. I'm not sure how the use of attachpoints for single objects differs from just placing the object itself in a Gmax layout, but it could provide a better option for library objects that are repeated. The only drawback I see with this method over hand-coding the locations of various library objects is that you lose the ability to have the objects conform to the terrain height. Even that isnt' a problem if you are building everything on a flattened surface, however. Interesting indeed!thx,

>Why not have the best of both? Put your objects in a library>then array the attach points in the scene. You couldn't see>how the array actually looks in gMax other than for the>location of the objects but that should keep the scene file>smaller. Could this not work?... and this is exactly what I did in the first place, since at the time, I thought it was the most-optimised solution. I guess the fact that I will end up with a much smaller file size is a benefit too. Like Bill says, the biggest problem was calculating all the attach points, but all I had to do was remember my high school trigonometry...Wait - my algebra teacher was right - there ARE real world applications for trigonometry. I guess I'll have to write him an apology letter.- Martin