Vasja Stanta

Hi Pavel, I believe my findings (at least on my system) pointed to my code being safely used in TGLFreeForm class. There seems to be very little (if any) performance impact and the Octree building process in TGLFreeForm and it becomes multithread safer (I have not tested this enough to claim it is 100% multithread safe but I am quite confident). Thank you for your time. I leave the usage of the code to your judgement. :) Regards, Vasja

Hi Pavel, I believe my findings (at least on my system) pointed to my code being safely used in TGLFreeForm class. There seems to be very little (if any) performance impact and the Octree building process in TGLFreeForm becomes multithread safer (I have not tested this enough to claim it is 100% multithread safe but I am quite confident). Thank you for your time. I leave the usage of the code to your judgement. :) Regards, Vasja

Hi Pavel, I checked the various demos and they mostly relate to Octrees themselves rather than TGLFreeForm. The modification above has no performance impact to those demos at all. Since the call to a TGLFreeForm.BuildOctree is usually done in an "intialization" or "preparation" phase, the performance while "running" is not impacted. The performance penalty might come from constant loading and building of octree on the fly. I did actually do a few tests based on the model in the demo "collisions/octreedemo"....

Hi, I have a bunch of TGLFreeForms that are being loaded in my app. The models are being loaded in a timely manner but since the octree build process can be somewhat lengthy I run the build process in a separate thread. (The model is displayed to the user, the octree is built "behind the scenes"). While this process works 99% of the time, we incurred in a scenario, where the octree was only "partially" built. Some parts of the model were "unreachable" by OctreeRayCastIntersect. After some research...