Crash Detection code

[rhumbaflappy 113]

Hi Arno.I also wonder about the way objects are called from libraries.Some code I've looked at calls the shadow first, then the perspective. Is that better? or does it make no difference. And with the crashcode, in the Library, as part of the object, aren't we calling that code twice... once with the shadow and once with the perspective? That seems a little wasteful of CPU time and memory... that's what made me wonder if a library containing objects designed to be placed by the hundreds ( Gerish's trees ? ), wouldn't crashcode be a CPU drag, as the crashcoding is called over and over ( and we probably don't want it at all ). ( I think Gerrish stated his trees don't have a crash code anyways ).I don't think we can turn off a library object's crash detection. So perhaps this is a designer's choice. And with addon libraries ( of which we have few ), 2 'flavors', crash and crash-free, might be a good way to distribute them. Dick

[arno 1]

Hi Dick,>Some code I've looked at calls the shadow first, then the >perspective. Is that better? or does it make no difference. I guess that must be old code then :). I know for example VOD used code like that in the Fs98 times, but this code is not correct and gives problems with transparant textures for example. The correct way to make any 3D object (so also call a library object) is to do the PerspectiveCall first and then the ShadowCall.>And with the crashcode, in the Library, as part of the >object, aren't we calling that code twice... once with the >shadow and once with the perspective?Don't think so, although they both refer to the same label, leaving out the shadow gives you no shadow and leaving out the perspective also gives problems, so they are both needed. So I don't think we call them twice, but if someone else has some extra thoughts on this it would be nice :).>I don't think we can turn off a library object's crash >detection. So perhaps this is a designer's choice. I think it's like that, just like with normal objects. Then it is also a choice of the designer to put it in or not (the user can always disable the crash using the settings of course).Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[rhumbaflappy 113]

Hi Arno.Just for fun, I messed with the shadow calling:; ----------------------------------------; DelavanStateCapitol.sca ( Sco_statecapital1 ) ; ----------------------------------------Header( 1 N42:38:01.80 N42:38:01.80 W088:36:33.00 W088:36:33.00 )LatRange( N42:38:01.80 N42:38:01.80 )Area( A N42:38:01.78 W088:36:33.00 100 ) IfVarRange( : 0346 2 32767 ) PerspectiveCall( :_PlaceObject_1 ) ShadowCall( :_Placeshadow_1 ) Jump( : ):_PlaceObject_1 RefPoint( rel :ReturnObject_1 0.3 N42:38:01.80 W088:36:33.00 V1= 0 V2= 187 ):RotateObject_1 RotatedCall( :CallObject_1 0 0 0 ) Return:CallObject_1 CallLibObj( 0 B86CAFDA 49133A72 85C23CA8 D335043F ):ReturnObject_1 Return:_PlaceShadow_1 RefPoint( rel :ReturnShadow_1 3.0 N42:38:01.80 W088:36:33.00 V1= 0 V2= 1870 ):RotateShadow_1 RotatedCall( :CallShadow_1 0 0 90 ) Return:CallShadow_1 CallLibObj( 0 0C545A2A0 011D2E2EC 01000849C 02AE60C5A ):ReturnShadow_1 ReturnEndAThe playing with the shadowcalling had no effect on the sim. The shadow was right regardless of scale or rotation of the shadow, and even calling a different GUID, had no effect. The shadow was fine if it was called, the parameters are useless.Then I tried this:; ----------------------------------------; DelavanStateCapitol.sca ( Sco_statecapital1 ) ; ----------------------------------------Header( 1 N42:38:01.80 N42:38:01.80 W088:36:33.00 W088:36:33.00 )LatRange( N42:38:01.80 N42:38:01.80 )Area( A N42:38:01.78 W088:36:33.00 100 ) IfVarRange( : 0346 2 32767 ) PerspectiveCall( :_PlaceObject_1 ) ShadowCall( :ReturnObject_1 ) Jump( : ):_PlaceObject_1 RefPoint( rel :ReturnObject_1 0.3 N42:38:01.80 W088:36:33.00 V1= 0 V2= 187 ):RotateObject_1 RotatedCall( :CallObject_1 0 0 0 ) Return:CallObject_1 CallLibObj( 0 B86CAFDA 49133A72 85C23CA8 D335043F ):ReturnObject_1 ReturnEndAHere, the shadow call points to a return! And the shadow is fine in the sim. This leads me to believe that the object is called only once, by PerspectiveCall, and the ShadowCall is only a switch. I'm thinking the whole works is only executed after the EndA is reached.. so it must reside on a 'stack' of some type, until the EndA releases the object to be displayed. This also makes me suspicious of CrashIndirect... if it switches on nothing, it will have no effect, and can be left out of future coding. I already tried changing the density activation of CrashIndirect, and that had no effect.Dick

[Guest GerrishGray]

More interesting discoveries.So these days ShadowCall() is nothing more than a 'switch' that turns on the shadow generation process for the current PerspectiveCall() object, and the label argument is there only for backwards compatibility with older code. Intriguing.--------I don't see that there is a lot of connection with Crash / CrashIndirect though. Crash detection does not operate on the current PerspectiveCall() object in the way that shadow generation does. It always requires its own definition of the 3D space that is to generate crashes, and the code is essentially separate from that relating to the drawing of the object. It has always been the same. All that is shared is the RefPoint() etc. that establishes the position, scale and local coordinate system for the object.I do not think that trying to understand the real execution sequence of the different processes that are going on here is necessarily essential, or even always helpful. The processes are much more complicated than is revealed by a simple reading of the code. This might look like traditional 'procedural' program code (i.e. code that gets executed in a step-by-step sequence that can be traced by reading the sequence of the commands and associated jump, loop and subroutine call structures), but the reality of the FS engine is MUCH more complex than that.Nor do I think that we need to understand these processes to determine whether crash detection or shadow generation have an effect on frame rates. Of course they do - both consume processor time and use memory resources. Of the two, shadow generation is almost certainly the bigger load because it adds an extra element to the complex and demanding frame drawing process. I don't think it was any accident that MS wanted to leave shadow generation out of FS2000 until faced with a scream of protest from users, and then had all sorts of problems when they decided to add it back in.RegardsGerrish

[arno 1]

That's a nice discovery :), now it makes sense that they point to the same label....Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[rhumbaflappy 113]

Hi Gerrish.I agree. I don't think we need to look beyond what works. I think Arno is right in that the "ShadowCall()" should immediately follow the "PerspectiveCall()". And pointing to the "CallLib()" assures it will find the "Return" statement it needs.The "Perspective()" call used to point to a "Perspective" command... that "Perspective" command is no longer needed.Likewise, "CrashIndirect" seems to no longer be needed when calling library objects. And the crash routine should be in the object library, with the object, if an object library is used.And designers, using Gmax and FSregen to build object libraries, must manually add the crash detection to the FSregen produced code. FSregen only adds the object, not it's crash code.Dick

[Guest luissa]

>Here, the shadow call points to a return! And the shadow is >fine in the sim. This leads me to believe that the object is >called only once, by PerspectiveCall, and the ShadowCall is >only a switch. Hi Dick,I have a set of 3D models of static aircraft. They go to a library and use a single texture. I load the texture in the calling code. Therefore I use the same model for different airlines. The calling code had a PerspectiveCall() and a ShadowCall(). I was very worried about a large number of textured polygons being called a second time just to draw a shadow. I made some consistent tests with a number of these static aircrafts placed side by side. I do not remember the exact numbers regarding frame rate loss, but if I had, say, 15 frames/second with both PerspectiveCall() and ShadowCall(), the number went up to, say, 25 f/s when I removed the ShadowCall(). Therefore I made a simpler model for the shadow by opening my original detailed model in FSDS and clearing all textures and desactivacting shading. So I had 2 objects in the library for the same aircraft. One for the object and one for the shadow. Then I used different labels for the PerspectiveCall() and ShadowCall(). If I had 15/25 (with/without shadows) before, I had 20 frames/second with the low resolution shadow.Therefore I do not understand how the ShadowCall() can be just a switch.Regards, Luis;ASDesign Compatible Macro;Name=A340, Type=Jets, Bitmap=a340.bmp, ;FixedLength=60, FixedWidth=64, ;Latitude, Longitude, Rotation, Density=0, ;Visibility=5000, Elevation=0, Shadow=0, ;AirLine=tp,; --------------------------------------------; A340.SCM SCASM macro for Flight Simulator; -------------------------------------------- ; This is an AirBus 340-300; October 2001Area( 5 %1 %2 10 )IfVarRange( : 346 %4 5 ) PerspectiveCall( :pcall )Jump( :shadow ):pcallPerspectivemif( %6 ) RefPoint( 2 :ret 1 %1 %2 e= %6 v1= %5 V2= 200 )melse RefPoint( 7 :ret 1 %1 %2 v1= %5 v2= 200 )mifendSetScaleX( :ret 0 0 9 )TransformCall( :start 0 589 0 0 0 0 0 %3 0 ):retReturn:tableDba( %8 ):startVarBase( :table )Var2Low64k( 312 0 )CallLibObj( 0 A28F1CD8 267300EC 022E0DB1 C0F65F5C )VarBase( :[-1] )Return:shadowmif( %7 ) ShadowCall( :scall ) Jump( : ) :scall mif( %6 ) RefPoint( 2 :ret1 1 %1 %2 e= %6 v1= %5 V2= 200 ) melse RefPoint( 7 :ret1 1 %1 %2 v1= %5 v2= 200 ) mifend SetScaleX( :ret1 0 0 9 ) TransformCall( :sstart 0 589 0 0 0 0 0 %3 0 ) :ret1 Return :sstart CallLibObj( 0 A28F1CD9 267300EC 022E0DB1 C0F65F5C ) ReturnmifendEndA

[arno 1]

Hi Luis,Humm, this indeed shows that it is not just a switch. But Dick also got a shadow while pointing to a Return command, so I find it hard to match those two. Let me do some tests with this.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[arno 1]

OK, just did a quick test and I could reproduce both results. So pointing at the Return gave me the correct shadow, but I could also add the shadow of an other object by pointing to that code.Can't find a good reason for this yet :)Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[rhumbaflappy 113]

Hi Arno.In my test, I used the original House project from MS's Gmax tutorial... but I forgot to reset the units in Gmax 1.2 and got a HUGE house. :-lol Meters became feet.So, I've grown fond of this object and now use it for experiments.In the above example, I not only pointed the shadowcall to just a Return to get a shadow, I also pointed it to a different GUID and got a shadow. That GUID was a default cruise ship... and the shadow was the correct size and shape for the huge house, not the cruise ship's shadow.That tells me the Shadowcall has no relationship to the CallLib command at all. It is a switch. What occurs after that switch is turned on, I don't know.I'll play some more with it today, as well. But if I can get a correct shadow with another object's GUID, or no object's GUID referenced at all, I don't know what more could be said about it.Dick

[Guest GerrishGray]

The net conclusion from all this seems to be that ShadowCall() should be used exactly in accordance with the SDK, and there is no profit from trying to do anything else with it. It would be very interesting if we really could draw a simplified shadow, or even a shadow of a different object (such as a static version of a rotating sprite), but Dick and Arno's tests seem to show that this is not possible. I'm not clear why your test results seemed to disagree with the others, Luis, but are you sure that you were seeing a different shadow?Exactly how ShadowCall() works since FS2000 doesn't really matter. Of course it is a 'switch' that turns shadow generation on, and of course it doesn't execute the code of the object in a straightforward procedural fashion - that much is obvious, surely. The only interesting point was whether we could do anything worthwhile by pointing its label somewhere else, and it seems not. In fact it seems that the current version actually doesn't take any notice of the label and it is only there for backwards compatibility. It probably needed the correct label before FS2000, but the shadow generation code was probably completely re-written after M$ initially discarded it and then had to put it back into FS2000. As both SCASM and BGLC need a label in their syntax (and so does BGL), we still have to put it there and might just as well go on making it point to the same label as PerspectiveCall(), if for no other reason than to make sure that we are not creating some other unwanted side effect.By the way, Luis, you really don't need that Perspective statement any more - it has been obsolete for ages and is just treated as a NOP (no operation). The SDK says so (page 86, BGL_BGL) and I did some testing to make sure that it is true! It's just Manfred's non-updated SCASM documentation that goes on misleading everybody.I tell you what though guys, these recent threads concentrating on the workings of an individual command or feature are proving really revealing and useful, don't you think (even if we do go off at a tangent trying something else as well). What's the next topic?CheersGerrish

[rhumbaflappy 113]

Hi Gerrish.Of course, you are right. The ShadowCall() is needed for a shadow, and it only needs to point to code that eventually delivers a return... so why not just use it as documented? Absolutely.DickP.S.Has anyone ever made a working object exception?

[Guest GerrishGray]

Hi DickI haven't used this since the days of the old AreaKill tool that did much the same thing except that it patched the BGL file direct - do you remember that?The problem with the present Exception command is determining the data needed to make it operate. First you have to identify and locate the Area() / OBJECT_HEADER for the object you want to kill, using BGLAnalyze for example, and then you have to inspect the code with a hex editor to get the exact value of the relevant size byte it seems. Sounds like a complete pain in the neck when you can generally do it with an Exclude covering a small area instead. An Exception only seems to be required when there are other objects located at the same position, or very close by, which you don't want to exclude.Maybe we could even build a little tool like the old AreaKill to help do the job? Or maybe Winfried might want to add it as a facility to BGLAnalyze - which needs updating anyway to overcome the problem caused by the spurious Return in so much gMax-generated code.Perhaps you should start a new topic called 'Exception() command' ... and when we have all the information we need we can pass it to Winfried.RegardsGerrish

[Guest christian]

Dunno if this help, but this is what I think how FS2002 works if it would be programmed in OpenGL. Of course it uses DX, but the graphic routines should be similar.First we have do define an object with all the vertices, texture coordinates, etc... Let's call it glObject.Then we draw it with the perspective call:first rotate the object using glMatrix and then draw all the vertices / polygons using glDraw.If we use shadowcall, we don't draw the object, but a shadow instead. FS2002 uses projected shadow, ie it only projects a shadow onto the ground, but not onto other objects.So, again we do a glMatrix, but this time to project the object onto the ground and then we draw the object. If this isn't supported by the hardware, this is quite an expensive operation.In a sense shadowcall is a switch, since it decides which routine to call, the normal rendering one or the shadow rendering one...Of course this is pure speculation, but this is how these things are usually done and every thing else would really be nonsense.In regards, can we draw a different shadow model to the one we are using, I think yes. I have seen this done by the default scenery library objects and it should be done when we have a complex model to save framerates. The way to do it is to use a low poly LOD model for the shadow. I haven't tried this myself yet, but it's on my huge 'todo' list...Cheers, christian

[Guest luissa]

> ... I'm not clear why your test results seemed to >disagree with the others, Luis, but are you sure that you >were seeing a different shadow? Hi Gerrish and all,Yes. I tried different "shadow objects". In simpler shadow models, the aircraft wings, for example, were just ploygons. I also deleted the engines and I remember to see the shadow of the wing without the shadow of the engines. I decided for "shadow engines" made of tubes with 6 sides instead of the 16 I used for the real model. >By the way, Luis, you really don't need that >Perspective statement any more - it has been obsolete for >ages and is just treated as a NOP (no operation). The SDK >says so (page 86, BGL_BGL) and I did some testing to make >sure that it is true! It's just Manfred's non-updated SCASM >documentation that goes on misleading everybody. Yes, thanks. I am not using it anymore. Regards, Luis