RefPoint question

[spotlope 0]

I've been designing scenery for a few months now, and I've figured out a number of the nuances, though not all by a long shot ;-). One thing that I'm still a little unclear on, however, is the importance of the refpoint of various buildings and scenery objects. Specifically my question is this: I'm working on a project right now in which it would be substantially easier to lay out my buildings in Gmax around a common central point and then export them as groups of bgls. Are there drawbacks to this method? I'm assuming that if I designed a large group of buildings spread around a field and used the field's center as my 0x 0y position in Gmax then the objects would all have a common refpoint -- is that right? And if so, what could be the problems that arise from that situation? The only reason I'd separate them into multiple bgls is to change the scenery density at which they appear so I can degrade the airfield selectively for users with lower-end systems. Thoughts?thanks,

[rhumbaflappy 113]

Hi Bill.One problem would be elevation. A singular refpoint would have all objects at the same elevation ( I think ). So the area would need to be flat as a pancake.Dick

[spotlope 0]

Yeah I thought about that. In the particular case I'm talking about, it's not an issue. Of course, I guess if you knew the variations in elevation you could actually build them into the Gmax file as well. It'd be tedious but would probably work. Other drawbacks?

[rhumbaflappy 113]

Hi Bill.There might be other problems. Your "V2" would be large to cover all the buildings, and that would exclude autogen within that area. Also, the "V1" would snap all the objects into view simultaneously at the maximum view distance from the refpoint... for a very large area, that would be a problem.Personally, I would let each object have it's own refpoint, as I don't see individual placement as a problem. But, I think you could use a single refpoint without too much fuss.Hopefully Arno or Gerrish will chip in if there is a "trap" in using a single refpoint that I haven't listed.Dick

[spotlope 0]

Thanks, Dick. Those are good points and I'll keep them in mind. I'm still working on my "general theory of scenery relativity" to use as a guide for developing a technique, and part of it is gaining a greater understanding of the variables involved. Is there somewhere online that's a good place to go for an overview of issues like the V1 and V2 attributes of scenery objects? I've tried to find resources that talk specifically about scenery design issues, but haven't come up with a lot.thanks,

[bob.bernstein 0]

Bill, in my last few projects I've found the best way for me is to design the entire project within a single gmax file. Thus when I check the work, I'm establishing a single refpoint. Its kind of convenient, I've made a box the size of my airfield and textured it with a high res image of the ground at the airfield, and frozen that box, so it can't be selected. Then the buildings are very simple to place accurately.Then when I'm getting close to the end, I make copies of that file equal to the number of buildings or in some projects I've grouped several buildings into a single file. then all one has to do is set up an organized delete process, so when your done, each structure remains within one of the file, and you end up with a dozen bgls within ur scenery.IMHO, this is the ideal way to distribute the files, with individual refpoints per structure you give the user the best frame rates.Best,Bob Bernstein

[spotlope 0]

That technique was what prompted me to make this post in the first place, Bob, so we're on the same wavelength. I was considering something of the sort, but it seems as though when creating scenery in Gmax, the resulting export uses the 0,0 of the gmax file as the location of the refpoint. That is, if you make a building 60' to the west of the central point in Gmax, when you export it the resulting file will have the building's refpoint set to 60' east of the building. Has that been your experience? If so, it might be a problem, albeit minor, with having the buildings pop in visually when close to a certain point, as that point isn't near the building. Again, I'm not sure this is an issue, but I'd like to clear it up once and for all in my own mind. What do you think?thanks,

[bob.bernstein 0]

good point, here's a test, but I'm real weak at reading bglc...would someone help with where the refpoint is specified? Two examples, one a hanager, and another is a trailer type fbo. Sperated by about 100 yards. Initially produced as one, then the files copied and each building compiled seperatedly. The big question is do they have different refpoints.FIRST ONE______________________________________________________;compile with BGLC /BGL C:airphotosequimsceneryfbo_finalpart.asmheader label word dw 0001 ; 00 World set number dd 000519024H ; 02 North bound dd 000518EE6H ; 06 South bound dd 0A86675F0H ; 10 East bound dd 0A86675EEH ; 14 West bound dw 20 dup(0) dd (offset OBJECT_DATA) - (offset header) dw 33 dup(0) OBJECT_DATA label word db 21 ;;LATBAND_REL dw 028C7h ;;lat min (inclusive) 512M units dw 028C9h ;;lat max (exclusive) dd (offset OBJECT_0) - (offset OBJECT_DATA) db 0 ;;EOL OBJECT_0 label BGLCODE db 12 ; NEAR_FAR_HUGE_OBJECT_HEADER dd 000518F85h,0A86675EFh ; latitude,longitude db 100 ; image power dd (offset OBJECT_0_END) - (offset OBJECT_0) OBJECT_0_START label word IFIN1 OBJECT_0_FAIL, image_complex, 2, 32767 ADDOBJ OBJECT_0_SCALE SHADOW_CALL OBJECT_0_SCALEOBJECT_0_FAIL label BGLCODE BGL_JUMP_32 OBJECT_0_END OBJECT_0_SCALE label BGLCODE SCALE_AGL OBJECT_0_RETURN, 10000, 159, 131072, 000518F85h, 0760Bh, 0A86675EFh, 038B9h, 0, 0 BGL_CALL OBJECT_0_BEGINOBJECT_0_RETURN label word BGL_RETURNOBJECT_0_BEGIN label wordmodel_outside label BGLCODE BGL_CALL model_crashmodel_shadow label BGLCODELOD_0 label BGLCODE BGL_JUMP_32 LOD_0Lmodel_inside label BGLCODE BGL_RETURNmodel_crash label BGLCODE BGL_CRASH_START model_crash_end, 317 BGL_CRASH_OCTTREE crash_end_1 dw CRASH_FLAG_OBJECT ; crash type dw 7 ; nodes used real4 36.150829,-0.000855,288.438385 ; Box x,y,z real4 44.482830,14.827610,25.706316 ; Box w,h,d dw 1, 2, 2, 3, 4, 4, 5, 6 ; base offset into node table, one for each top-level branch ; So if you take branch 2 (count from 0), you add 2 to indices you encounter on that branch ; Nodes (254=empty 255=full, else an index into branch) OCTTREE_NODE 0, 255, 0, 0, 255, 0, 0, 0 ; node 0 OCTTREE_NODE 254, 254, 254, 254, 255, 255, 255, 255 ; node 1 OCTTREE_NODE 254, 254, 254, 254, 254, 255, 254, 254 ; node 2 OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 3 OCTTREE_NODE 255, 254, 255, 254, 255, 254, 255, 254 ; node 4 OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 5 OCTTREE_NODE 255, 254, 254, 254, 255, 254, 254, 254 ; node 6crash_end_1 label wordmodel_crash_end label word BGL_RETURNLOD_0L label BGLCODE include C:airphotosequimsceneryfbo_finalpart_0.asmOBJECT_0_END label wordEOF____________________________________________________________SECOND ONE____________________________________________________________;compile with BGLC /BGL C:airphotosequimsceneryhangar_finalpart.asmheader label word dw 0001 ; 00 World set number dd 000519332H ; 02 North bound dd 000518BD8H ; 06 South bound dd 0A86675F0H ; 10 East bound dd 0A86675EEH ; 14 West bound dw 20 dup(0) dd (offset OBJECT_DATA) - (offset header) dw 33 dup(0) OBJECT_DATA label word db 21 ;;LATBAND_REL dw 028C5h ;;lat min (inclusive) 512M units dw 028CAh ;;lat max (exclusive) dd (offset OBJECT_0) - (offset OBJECT_DATA) db 0 ;;EOL OBJECT_0 label BGLCODE db 12 ; NEAR_FAR_HUGE_OBJECT_HEADER dd 000518F85h,0A86675EFh ; latitude,longitude db 100 ; image power dd (offset OBJECT_0_END) - (offset OBJECT_0) OBJECT_0_START label word IFIN1 OBJECT_0_FAIL, image_complex, 2, 32767 ADDOBJ OBJECT_0_SCALE SHADOW_CALL OBJECT_0_SCALEOBJECT_0_FAIL label BGLCODE BGL_JUMP_32 OBJECT_0_END OBJECT_0_SCALE label BGLCODE SCALE_AGL OBJECT_0_RETURN, 10000, 941, 131072, 000518F85h, 0760Bh, 0A86675EFh, 038B9h, 0, 0 BGL_CALL OBJECT_0_BEGINOBJECT_0_RETURN label word BGL_RETURNOBJECT_0_BEGIN label wordmodel_outside label BGLCODE BGL_CALL model_crashmodel_shadow label BGLCODELOD_0 label BGLCODE BGL_JUMP_32 LOD_0Lmodel_inside label BGLCODE BGL_RETURNmodel_crash label BGLCODE BGL_CRASH_START model_crash_end, 1881 BGL_CRASH_OCTTREE crash_end_1 dw CRASH_FLAG_OBJECT ; crash type dw 20 ; nodes used real4 -1345.549438,-7.655502,-698.509033 ; Box x,y,z real4 2840.000244,946.666748,1840.000244 ; Box w,h,d dw 1, 6, 6, 6, 6, 13, 20, 20 ; base offset into node table, one for each top-level branch ; So if you take branch 2 (count from 0), you add 6 to indices you encounter on that branch ; Nodes (254=empty 255=full, else an index into branch) OCTTREE_NODE 0, 254, 254, 254, 0, 0, 254, 254 ; node 0 OCTTREE_NODE 254, 254, 254, 254, 254, 1, 254, 254 ; node 1 OCTTREE_NODE 254, 254, 254, 254, 2, 254, 254, 254 ; node 2 OCTTREE_NODE 254, 254, 254, 254, 254, 3, 254, 254 ; node 3 OCTTREE_NODE 254, 4, 254, 254, 254, 254, 254, 254 ; node 4 OCTTREE_NODE 254, 254, 254, 254, 254, 255, 254, 254 ; node 5 OCTTREE_NODE 254, 1, 254, 254, 254, 254, 254, 254 ; node 6 OCTTREE_NODE 254, 2, 254, 254, 254, 254, 254, 254 ; node 7 OCTTREE_NODE 254, 3, 254, 254, 254, 4, 254, 254 ; node 8 OCTTREE_NODE 254, 254, 254, 254, 254, 5, 254, 254 ; node 9 OCTTREE_NODE 254, 6, 254, 254, 254, 254, 254, 254 ; node 10 OCTTREE_NODE 254, 254, 254, 254, 254, 255, 254, 255 ; node 11 OCTTREE_NODE 254, 255, 254, 255, 254, 254, 254, 254 ; node 12 OCTTREE_NODE 1, 254, 254, 254, 254, 254, 254, 254 ; node 13 OCTTREE_NODE 2, 254, 254, 254, 254, 254, 254, 254 ; node 14 OCTTREE_NODE 3, 254, 254, 254, 4, 254, 254, 254 ; node 15 OCTTREE_NODE 254, 254, 254, 254, 5, 254, 254, 254 ; node 16 OCTTREE_NODE 6, 254, 254, 254, 254, 254, 254, 254 ; node 17 OCTTREE_NODE 254, 254, 254, 254, 255, 255, 255, 255 ; node 18 OCTTREE_NODE 255, 255, 255, 255, 254, 254, 254, 254 ; node 19crash_end_1 label wordmodel_crash_end label word BGL_RETURNLOD_0L label BGLCODE include C:airphotosequimsceneryhangar_finalpart_0.asmOBJECT_0_END label wordEOF

[spotlope 0]

I'm not stellar at reading asm files either, but I'm slowly getting better. The thing that made me think the file had the same refpoint is that you can make a building in Gmax and export it to a particular location. Then move the building in Gmax considerably and re-export it to the same location as before. If you're like me, you'll find that the building has moved a corresponding amount in FS as well, indicating that the location of the refpoint is always the 0,0 in Gmax regardless of where you place the building.

[arno 1]

Sorry Bob, that is fooling yourself :). If you just copy the file and then remove the other objects they will still all have the same RefPoint. And this the v1 will still not be relative to the middle of the object. Also the v2 value is much to large and that can have an influence on the frames. If you do it this way, you can just as well save yourself the work of deleting the objects and export as one file.

[arno 1]

SCALE_AGL OBJECT_0_RETURN, 10000, 159, 131072, 000518F85h, 0760Bh, 0A86675EFh, 038B9h, 0, 0SCALE_AGL OBJECT_0_RETURN, 10000, 941, 131072, 000518F85h, 0760Bh, 0A86675EFh, 038B9h, 0, 0This are the RefPoint from both files, look for the differences I would say :). Only the v2 value seems to be different (159 compared to 941), but the rest is the same. I guess the second object is bigger or further from the center.I just wrote in the post I just placed this way does not help your performnace.

[arno 1]

Hi Bill,I would not do it this way. For small projects you might not notice the difference in performance, but for a big project I can tell you that minimizing the v2 values can have a very good influence on the frames. To be able to do this, it is best to have the RefPoint of each object in the middle of it. This can only be done if it is at the 0,0 coordinate in GMax.This also has the advantage that you can set a different v1 for each object and thus let big objects appear earlier then small and less important ones.I am working on a little tutorial about the v2 value and it's importance now, I hope I can finish that soon.

[spotlope 0]

Thanks for the reply, Arno. I eagerly await your tutorial! So given the possible issue with the placement method suggested above, I've got a different question. What about the plusses and minuses of creating APIs of my Gmax objects in FSRegen and placing them using one of the commonly available freeware tools like Airport for Windows or FSSC? I know they both are really intended for older versions of FS, and neither seems particularly adept at the more recent innovations. For instance, they don't know anything about VTPm2 polys, lines, LWM masks and the like. Also, I've never been sure if there's any sort of performance hit from using SCASM as the scenery language and compiling through it vs. doing it in bglc. What are everyone's thoughts on that subject? And yes, I am writing a paper. For the Avsim conference, in fact. I'd like to publish outtakes from that paper as I write it here on the message board for feedback if you're interested. You guys are the most knowledgable group of scenery designers around, and I'd love to have your input.thanks,

[arno 1]

Hi Bill,As long as you use the same commands a scenery made with SCASM or BGLC will have the same performance, because they are both just a compiler to create a BGL file. So if you put the same commands in the output BGL is the same.Having said that, lets try to answer the other questions :). I usually make library objects out of my GMax objects and place them with FSSC then. The code used by a macro that call a macro and also the placement code of the macro is very simple and this will not have a performance hit.But I think you are correct that the code of some of the other scenery objects (polygons, taxiways) etc is sometimes a bit outdated in these tools. I think most developpers want to add the new floating point commands and the mesh scenery as well, but they just need a lot of time and testing to get it to work.For my bigger airfields (mainly EHAM that is), I have therefore made my own tool to place the polygons etc (that way I can use the latest floating point commands already (like GMax), but also there I still use the macro calls like FSSC and Airport do).For my smaller airfields I use FSSC. These only contain a small amount of polygons and roads etc and then there will not be a very big performance hit. I also think (but I newer tested it, so I have no figures about it) that GroundMaker and FSSC produce scenery that is a little bit more efficient then Airport (I think Airport has more old source code left in the SCASM source).And yes I am certainly interested to have a look at your paper if that helps you :). It's a pity that he conference is that far away, I would love to visit it also.

[arno 1]

OK here is it, it explains the basics of the v2 value. I hope it makes clear why the value is that important for good performance (or maybe I can better say that misuse of it has a bad influence on the performance).http://www.scenerydesign.org/modules.php?n...rticle&artid=17