Crash Detection code

[Guest GerrishGray]

Yes, what I was saying about CrashOctTree was that there was no logic in placing it in the calling api if one is using a library object. It's better off in the library object. But it can of course be used in section 9 objects as well - that is how gMax uses it.I have never included crash detection in my trees because frame rate efficiency is SO important with trees. But that situation is changing because Autogen now provides the majority of the background trees and individually programmed trees like mine are now only needed for the immediate surroundings of a scenery, where crash detection is possibly more important (e.g. on runway approaches and when taxying around an airfield). I might even add crash detection to a future version of the trees library, perhaps as a selectable option, but I haven't made my mind up yet whether to bother (and that isn't why I started this thread - that was motivated merely by a desire for better understanding!).To return to the original question, what we need to clarify is whether CrashIndirect() is EVER required in FS2002, or whether crash detection code in library objects always works fine without it. It's beginning to look as though this is a redundant command that actually does nothing in FS2002?I don't think that CrashIndirect ever created crash detection by itself - it's apparent purpose was always only to 'initialise' or activate crash detection in a library object in some way. The actual crash detection code using the other commands always had to be in the library object code anyway. Hence the puzzle of why CrashIndirect() was required, what it actually did, and why it no longer seems to be needed.Or perhaps all it effectively does is provide an independant control of the scenery density level at which crash detection becomes active?CheersGerrish

[Guest christian]

Just to add some random thoughts:The default FS2002 gmax library call bgls use crash_indirect if I remember right (I decompiled them). BUT makemdl doesn't place a crash_indirect in the BGLC source. As far as CPU hit is concerned, I think the octtree solution should allow for many, many objects with hit detection enabled, but if we want numbers, I guess we'd have to experiment...Cheers, Christian

[rhumbaflappy 113]

Hi Christian.Am I right in assuming the OCTTREE commands are a "fitted" crash detection, instead of a radius or a box... Clinging more closely to the objects exterior 'skin'?---------------Here's a section of decompiled "cheklap_placement.bgl", from the 'hongkongscenery' folder:

; ----------------------------------------; Object # 1, offset: 0x0013 size: 111 bytes (0x006F) ;; Lat: 00025D6EFh Lon: 05104AB2Dh; ----------------------------------------Area( A N22:18:53.24 E113:55:54.82 100 )	IfVarRange( :  0346 5 32767 )	CrashIndirect( :L00006C :L000040 :L000060 0 0 )	ShadowCall( :L000040 )	PerspectiveCall( :L00003E )	Jump( : ):L00003E	Perspective:L000040	RefPoint( rel :L00006A  0.50 N22:18:53.25 E113:55:54.82		V1= 500 V2= 10 ):L000060	RotatedCall( :L00006C   0   0  67 ):L00006A	Return:L00006C	CallLibObj( 0 8C038540 4C47B71C FC133C87 904A8940 )	ReturnEndA

That object is found in vehicles.bgl... veh10 is the name, and the library object does seem to have CRASH_START and OCTTREE commands, as Christian indicated it might. It's an FS2002 FL-point object with 3 LODs ( that I can tell ).Attached is a pic.Odd. And I can taxi through the object, and it doesn't cause a crash.Dick

[Guest GerrishGray]

Hi ChristianWe started this conversation about CrashIndirect once before I remember, but never reached a firm conclusion as to whether it is actually needed in FS2002 or not. Dick's contributions seem to be suggesting that it may not actually be necessary in FS2002 (despite what the SDK still says), even though it still seems to be included in some of the code sequences used for calling library objects. I never really understood what it was supposed to do anyway, which is why I started this thread ...One possible hypothesis is that it controls the scenery complexity at which crash detection becomes active for any particular object (given that the object contains crash detection code anyway). This would enable higher-complexity scenery to use crash detection whilst a lower complexity setting would turn it off and save further on frame rates / CPU load. But if that is ALL it does (did?), why the need for all those labels as well - it looks more as though it was necessary for some sort of initialisation of the crash detection process to me, but I'm only guessing here and don't understand why it might have been needed in an earlier sim version but not, perhaps, now? Any useful thoughts?If only MS gave us proper reference documentation of the BGL language! It is Christmas in a couple of weeks so I'm entitled to dream the improbable ... but I don't really expect Santa Claus to be coming down my chimney with any such present from Redmond!Gerrish

[Guest GerrishGray]

Hi DickYes, an octtree can indeed produce an accurate representation of any solid shape, whether it is for crash detection purposes in FS or for some other purpose entirely.An octtree is a data structure that is designed to contain 'binary tree' data about a 3D space. The space is divided into 8 cells by dividing each of the three dimensions in half. Each cell can be successively halved into 8 more cells, to any required level of detail, thus creating a sort of binary tree in three dimensions.Hence the eight values at each node of the tree.By allowing recursive entry into the same node for different branch levels, the structure can be used to create a very accurate description of a 3D shape with sloping surfaces, pointed 'cusps' etc. with a fairly small amount of data. Rather like a fractal, each successive cell for some shapes is just a one-eighth size version of the cell containing it, so the same node data can be used over and over to any required level of detail.In the BGL version, a value of 255 is used to indicate a 'solid' cell that causes a crash, whilst 254 indicates an empty cell space with no crash potential. All other node values are pointers (or rather offsets) to other nodes that break the cell down into eight more cells. An offset of zero gives an infinitely re-entrant recursion into the same node. Like me, you might need to visualise, or draw, this in a 3D representation to understand.At least, that's my present understanding. Octtrees hadn't been invented in my day (i.e. when my poor old brain was still using a reasonable proportion of its grey matter), so I don't claim to be any sort of authority on the subject!!!Interestingly, the full specification for the DDS texture format available in DirectX includes provision for a 3D octtree version as an alternative to the 2-dimensional bitmaps we are accustomed to. Support for this might well be introduced in a future version of FS for modelling true volumetric 3D clouds etc - CFS3 has already adopted the DDS format in place of DXT, but I don't know whether it supports the 3D variant.At this rate, before long we are all going to need a degree in brain surgery or quantum physics (or maybe both) to understand how FS works!!!CheersGerrish

[rhumbaflappy 113]

Hi Gerrish.In the above example, The scenery density needs to be set to extreme density, or the object doesn't show... and it obviously is 3 LOD levels, each with their own crash OCTTREE. Does the 0 in the density parameter mean there is no crash? I think yes, because the library object does have crash code, and now needs something to deactivate it. It requires extreme density to show, and we could have aircraft crashing into an invisible object at lower density... so it deactivates the crash code of the library object, with the zero setting in the CRASH_INDIRECT call? Perhaps.So there is a use for CRASH_INDIRECT.Dick

[Guest GerrishGray]

Surely a 0 in the density parameter for CrashIndirect is going to turn crash detection ON at all density settings, not disable it? I think the value would need to be > 5 to turn crash detection off completely, or 5 in your example where the crash detection is only required at extreme density. But isn't there a density check in the calling sequence before the code ever reaches the CrashIndirect anyway?Gerrish

[rhumbaflappy 113]

Hi Gerrish.I think in:IfVarRange( : 0346 5 32767 )the 5 sets the object density as Extremely Dense:Sparse = 1Normal = 2Dense = 3Very Dense = 4Extremely Dense = 5... at least this is essentially what Gmax does:IFIN1 OBJECT_0_FAIL, image_complex, 3, 32767with 3 the setting for Normal. Zero isn't used in Gmax, as a condition doesn't need to be set if the density is Very Sparse... it always shows.------------Then:CrashIndirect( :L00006C :L000040 :L000060 0 0 )sets the crash detection to zero... or nothing. That's a guess, but I can verify tomorrow, that zero turns crash detection off... Very Sparse is again not needed, because the crash-code is in the Library object code, and doesn't need to be activated, if all levels will have the crash.I'm pretty sure you can 'tune' the activation of the crash separately from the scenery density activation.Dick

[Guest christian]

Hi Gerrishocttrees well explained, I couldn't have done it better...>One possible hypothesis is that it controls the scenery >complexity at which crash detection becomes active for any >particular object (given that the object contains crash >detection code anyway). I think this is a good theory, and it makes sense too!>But if that is ALL it does (did?), why the need >for all those labels as wellYou need those labels, because FS2002 still has to place and rotate the octtree (so it fits the visual object), at least that's what I'm guessing.>If only MS gave us proper reference documentation of the BGL >language! It is Christmas in a couple of weeks so I'm >entitled to dream the improbable ... but I don't really >expect Santa Claus to be coming down my chimney with any >such present from Redmond! Dream on. Just thinking about this subject brings my blood to boil :-fume I recently learned that SOME documents were floating around in the FS group for MONTHS, at a time I actually asked them for help about the TMF data structure. I got no replies and to think that they had all the answers I wanted sitting in documented form as an SDK which they never released... I have to stop here or I'm going to cry :'( Cheers, Christian

[ShezA 176]

:( Anyway...one question, if we have a scene with many buildings does the whole scene get the crash detection? or individual objects? am at work so do not have access to the asm file.Shez

[arno 1]

I haven't followed FreeSC that much lately, but the devellopment seems to be stopped (also) to me. But it should be more open to add new features.One problem with FreeSC is that it doesn't support the floating points yet, but maybe that can be added to it easily.Another small problem with it is that the a and ai options for polygons sometimes give a different result from SCASM (so the other side).I'll have a look again at FreeSC this weekend, as in principle it is an interesting compiler.The thought of making a BGLC-SCASM converter has been in my mind for a while already.At first I thought SCASM wasn't far enough for it yet (you can not make reflective textures with SCASM for example), but from what I have learned lately it seems useless to use them on buildings, as they don't work proper, so they are more intended for aircraft.This means that it should be very well reasonable to make a converter that allows you to create SCASM code from GMax/BGLC. I will do a bit of thinking on this (got some hours to sit on the train to go to the Netherlands this evening, excellent place to think :)).Arno

---

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

[Guest GerrishGray]

Hi ChristianYes, I think you may have hit the nail on the head for what CrashIndirect (for library objects) or Crash (for inline section 9 code) does/did. Some of the commands used for the actual crash detection work(ed) on the basis of 'raw' coordinates based purely on the RefPoint position and ignoring any rotation or transformation of the local coordinate space specified by an intervening RotatedCall or TransformCall command. Thus, Crash/CrashIndirect, with their pointers to the RotatedCall command etc. could be necessary to position and rotate the crash detection boundaries correctly, as you suggest. This would also explain why it seems to be quite hard to determine from testing whether the use of these commands is actually necessary - there would still be crash detection without them, but possibly based on a wrongly-oriented crash box or whatever.I note that the Microsoft house.asm sample code from the tutorial for the new commands does NOT include Crash, implying that CrashOctTree does not in fact need this initialisation, presumably because it is based on the rotated coordinate space, rather than the raw unrotated coordinates.CrashOctTree does include provision for an x,y,z offset because the origin of the coordinates for an octtree 'box' is conventionally at the bottom front left of the box, not in the middle of it. (This is presumably done so that the octtree space sits entirely in the segment with +ve coordinates for all three dimensions, thus allowing the halving of dimensions to be done by simple binary division without having to worry about allowance for -ve dimensions.) And it doesn't include any rotation offset because it isn't needed (?)This interpretation is consistent with the house.asm example. But it is not necessarily conclusive, because other interpretations could also be made to fit that one example, I suppose ... It needs to be checked against some different examples with other code structures/sequences. Not quite so easy because (a) gMax/makemdl.exe, I believe, always generates exactly the same code structure (complete with the spurious Return that gets BGLAnalyse so confused), while (:( Louis Sinclair's FSDS2 does its crash detection in a different way and © the unreleased NovaSim tool that I am helping Rafael Sachez with doesn't bother with crash detection anyway - I don't think any of Rafael's design tools ever have. I wonder if anyone has manually coded any examples (whether in SCASM or BGLC) that would give us the additional information we need to confirm this hypothesis? I really haven't got the time to devote to testing it myself - merely participating in these discussions and trying to collate the outcomes is taking up more time than I can really afford amongst numerous other priorities! I hardly ever have time for actual FS flight - and some fairly accurate flying will be necessary to completely test these hypotheses.There is one other question to be answered about CrashOctTree - we still don't know for certain the sequence of the eight cells in each octet relative to physical space. Presumably the first cell is the one adjacent to the origin, but which direction do we go in from there? This also needs confirming by some accurate testing - although it could just be done by building some simple shapes in gMax and inspecting the generated code, I suppose.(BTW, one of the objectives of my interest here is a notion I have of producing a web site with a 'proper' reference manual for BGL coding. I have actually created a web domain space for it, but it might take me a while before I can devote enough time to get it online with an adequate outline and enough initial content to make it worthwhile.)As regards MS, one has to remember that they work under commercial pressures, so although we might moan about them at times and get frustrated, the reasons for their 'errors and omissions' are actually perfectly understandable and forgiveable ;-)CheersGerrish

[rhumbaflappy 113]

Hi Gerrish.My initial enthusiasm with CrashIndirect has faded. I've played with this command for 2 hours, and it has no effect with library objects' crash detection at all. They always crash if the CRASH_OCTTREE structure is in the library object.And I agree that the code for the crash should be in the library object... otherwise it defeats the reason for having a library ( to save time and effort in repetetive coding ).So unless someone else can find a way to selectively turn off a library object's crash detection, then it must remain as an object's feature.As far as I can tell, CrashIndirect is not needed, or used at all, in FS2002.Dick

[Guest GerrishGray]

Yup Dick, that's roughly the conclusion I was reaching too. CrashIndirect (or Crash in inline code) probably isn't needed with the modern crash detection methods - the best theory seems to be that its purpose was to enable older methods to cope with rotated or transformed coordinates. The difficulty in confirming this by testing is that crash detection probably ALWAYS works without Crash/CrashIndirect anyway - it's just that it might get the accurate detection of collision with the crash 'box' wrong - i.e. one might get crashes generated by a non-collision in a space close to the crash box, and no crash despite collision with some solid object space. It would not always be easy to see whether this had actually happened. CheersGerrish

[arno 1]

This shouldn't be that hard to test, just make a rectangular box (let's see 500 x 50 meters or so) and rotate it 90 degrees. Then you should have a fair area where there is no crash but there is a building and the other way around.If I find some time this weekend I'll give it a try :).Arno

---

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