FSXA my curse with the shadows offset

[simulondo]

As I said before I work directly with blender to make my models and textures. At the beginning I exported them using MCX without problems until I activated the shadows in the FS options. Then I discovered this problem

After several tests I did not find the solution, so I started to export directly my models to gmax, and from it to .mdl. At the end I suspected that the problem was in my computer.

But Yesterday I tested in a fresh configuration computer and the result was the same.

some tips:
- I used the MCX last release and the cube´s center point is in its base.
- This problem only appears when I use MCX to generate the final .mdl. If I export the model from gmax everything is correct.
- It happens too when use a gmax´s model in MCX

Any clues?

I uploaded my .bgl here. The cube is in the Packwood´s airport (55s). If someone could test it I will appreciate it.

 

[Tejal Bernardo]

Hi, MCX say no objects found in file.
Are you having problems too with Gmax models?

 

[JRobinson]

My guess is "batched object shift", which seems to shift the model slightly but apparently not the shadow. The shift is exaggerated with altitude, to verify try placing your object on top of a mountain somewhere, I believe you'll see the shadow shift even more.

MCX batches models that don't contain LODs or animations by default. Direct exports from gmax are not batched which would explain why you only encounter the problem after processing the model through MCX. You could try adding an empty LOD so MCX doesn't batch the model. Of course you loose the benefits of drawcall batching when you do that.

Jim

 

[simulondo]

Hi, MCX say no objects found in file.
Are you having problems too with Gmax models?

Buenas Bernardo

ups, my fault, sorry. I´ve just re-uploaded the correct version (mdl+position).

Thank you sir

 

[simulondo]

My guess is "batched object shift", which seems to shift the model slightly but apparently not the shadow. The shift is exaggerated with altitude, to verify try placing your object on top of a mountain somewhere, I believe you'll see the shadow shift even more.

MCX batches models that don't contain LODs or animations by default. Direct exports from gmax are not batched which would explain why you only encounter the problem after processing the model through MCX. You could try adding an empty LOD so MCX doesn't batch the model. Of course you loose the benefits of drawcall batching when you do that.

Jim

Jim, you hit the nail!

I´ve just "batched" the model with an empty LOD and then the shadow appears correctly! Thank you so much!

But could you explain a little more the reason of this shift? I don´t understand it.

 

[Tejal Bernardo]

Cool solution, first time I heard about those batched objects in the exportation, I don't understand the process either as many things in the modelling stuff of course.

 

[arno]

Hi,

Hummm, that batched object shift is new for me as well. So I guess I need to add an option them to modelconverterx to make the unbatched mdl files like gmax does.

 

[JRobinson]

...could you explain a little more the reason of this shift? I don´t understand it.

I don't understand it either, that'd be one for Arno or Ian (hcornea). I think it has something to do with FSX's geocentric coordinates (round world). Apparently the further from the center of the earth you get the more the shift.

You'll also notice that if you place objects with Instant Scenery they will shift slightly when you restart the sim. This is because IS2 temporarily breaks batching while it's running so basically you're placing an unbatched model. When you restart the sim without IS2 running the batching returns and the objects shift slightly.

The shift seems to be consistent among models at a given altitude, I usually place objects into a temp .bgl with IS2, I then decompile it to XML and use macros to strip the coordinates from the XML, process them through an Excel spreadsheet, and put the adjusted coords back into the XML. The adjustment in my case (at 2330' MSL) is lat: -0.0000052, lon: +0.0000084 which I simply arrived at by trial & error.

Jim

 

[hcornea]

That's as good an explanation as I could come up with.

Of course if Arno could work out a solution for the placement file corrections, that would be appreciated by a great many.

 

[simulondo]

Thank you Jim for you answer. Let me ask you one thing more:

You'll also notice that if you place objects with Instant Scenery they will shift slightly when you restart the sim. This is because IS2 temporarily breaks batching while it's running so basically you're placing an unbatched model. When you restart the sim without IS2 running the batching returns and the objects shift slightly.

When you say unbatched or break batching, Do you mean that object doesn't exist like any other object in a BGL but it is something temporal?

The shift seems to be consistent among models at a given altitude, I usually place objects into a temp .bgl with IS2, I then decompile it to XML and use macros to strip the coordinates from the XML, process them through an Excel spreadsheet, and put the adjusted coords back into the XML. The adjustment in my case (at 2330' MSL) is lat: -0.0000052, lon: +0.0000084 which I simply arrived at by trial & error.

I follow the same method. But the worst part of this process is when I lose a lot of time adjusting the objects pos to fit with their ambient oclussion projected shadows (in the ground polys). I know perfectly the frustrating experience of having to change 0.00001 and reload the sim

 

[JRobinson]

When you say unbatched or break batching, Do you mean that object doesn't exist like any other object in a BGL but it is something temporal?

No I just mean the object behaves like an unbatched model (meaning a model that doesn't employ drawcall batching - like you get when you export straight from gmax). The shift problem isn't present, pitch & bank can be used in the placement, etc.

This all makes it sound like MCX does something undesirable to our models by batching them but that's not the case since significant performance gains are realized through drawcall batching, particularly when you have dozens of placements of similar objects, multiple vegetation objects that use the same material/texture sheet for example. It's best to leave the models batched and work around the undesirable effects.

I follow the same method. But the worst part of this process is when I lose a lot of time adjusting the objects pos to fit with their ambient oclussion projected shadows (in the ground polys). I know perfectly the frustrating experience of having to change 0.00001 and reload the sim

You should just work out an offset in lat & lon for your airfield that you can apply to all placements like I did. I can place a hundred objects, decompile the .bgl, run the coords through my spreadsheet, re-compile the .bgl using the adjusted coords, and all hundred objects fall into place over their shadows without all the fiddling, sim restarts, etc.

I made a sharp-edged bright red rectangle representing a hangar footprint on my ground poly, fired up IS2 and placed the hangar precisely on the rectangle. I decompiled that placement .bgl and set the XML aside as "unshifted.xml". Then I fiddled with the placement until I got the hangar to align perfectly with the red rectangle after a restart of the sim without IS2 running and decompiled that as "shifted.xml". The difference between the coords in unshifted.xml and shifted.xml became my offsets and I just use the spreadsheet to apply those offsets to all my IS2 placements.

Jim

 

[simulondo]

Thanks for the answer Jim. Now I understand it.

Regards to positions objects, in my case the offset is bigger as the object is far from the groundpoly´s origin, so I have to modify them by myself

I think it´s time to recover my C++ studies. The scenery development has reached such complexity level that it´s necessary to be able generate little apps or plugins to make easier all this stuff.