• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

SCDIS / SCASM unit / decimal problems

roger-wilco-66

roger-wilco-66

Messages
226
Country
germany
Hi,

I try more or less successfully to port a few default CFS2 objects out of the original libraries to FSX. It is a bit of work but it basically successful.

The bgls can be decompiled with SCDIS and then the sca files can be edited to make it basically FSX compatible. I think the code is very straight forward and easy to read, so this is indeed an easy task.

Unfortunatly, there seems to be a unit conversion problem in some libraries. It seems like the decimal break is omitted and a number like 10.00 (meters) becomes 1000 meters. First I thought I could cope with that by switching the regional config in Win XP, and then decompile, but this is to no avail.

Has anyone an idea how to deal with this?

Thanks,
Mark
 
Hi Mark,

It could be that in CFS the object was placed with a small scale. So you might actually have to scale it down.

Btw, did you check out my ModelConverterX tool? It should be able to make a FSX MDL directly from your (decompiled) SCASM code.
 
Hi Arno,

that is right, I have to scale it down by the factor 10 or 100. What is bothering though, is that in FSX the old footprint ( bounding box ? ) of the object is still active. You see that because there is no autogen where that footprint is, which is messing up the scenery of course. Maybe I'm missing something here?

And yes, ModelconverterX is the next step in my workflow. I use the batch convert utility to convert all the isolated and reprogrammed .sca files into mdl, and then use the librarycreatorx to pack them into a bgl. Works like a charm! I must make a huge compliment to you and your work on these excellent tools. Without them, I could not accomplish what I'm planning right now.

To come back to the problem:
Scaling down in the scasm code or in ModelconverterX would be the solution, but the autogen problem needs to be dealt with, too.
Is this maybe related to the "size" parameter in the ObjID header? Here is the code of one of the objects (note the large size and the ineffective and wrong (should be 0.001) Scale parameter and the size):

ObjID( 8E8F4969 45C8F8AD 9B46CFA4 2D65DC41 )
LibObj( PWR 0 SIZE 8160 SCALE 0.000977 TYPE 0x0 PROP 0 NAME "inf_control_tower_american" )

[...cut out some code...]

:L122
TextureList( 0
6 87 147 102 255 0 16.841055 "INF_Damage_misc.bmp"
)
MaterialList( 0
0.576471 0.529412 0.400000 1.000000 0.576471 0.529412 0.400000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000
)
VertexList( 0
-6144.000488 0.000000 7168.000488 0.000000 1.000000 0.000000 0.031250 1.601563
-6144.000488 0.000000 -7168.000488 0.000000 1.000000 0.000000 0.526042 1.591146
6144.000488 0.000000 7168.000488 0.000000 1.000000 0.000000 0.007813 1.010417
6144.000488 0.000000 -7168.000488 0.000000 1.000000 0.000000 0.526042 1.013021
)
SetMaterial( 0 0 )
DrawTriList( 0
1 3 0
3 2 0
)
Return

-------------------------8< snip end of code

I also included a few lines of the vertex definitions, and one clearly sees here that these are very large numbers for such a small object, hence the massive scale down and the huge footprint.


Thanks for your help,
Mark
 
Hi Mark,

Do you scale it down when placing it with the XML code or do you already use the scale function in ModelConverterX to make it smaller?

In the last case the bounding box should scale with it and I would not expect issues with the autogen. If you scale in the XML you can get such issues indeed.
 
Right now, I scale it with SBuilderX when I place the object (is this like the XML placement you mentioned?). SBX remembers the custom entries in the objects properties, so you only have to do it once.

I tried it in modelconverterx but found that somehow the change had no impact after the mdls were packed into the bgls and read into SBX.

I did not coninue to try it further, because the scaling worked in SBX (but with the autogen penalty). I figure it would be cleaner if the models were in the right scale in the bgl right from the start.

I'll have a look at it again!

Cheers,
Mark
 
Hi Mark,

It should work in ModelCoverterX. But if you keep having trouble you might have found a bug :). Let me know if it still does not work and I will take a look here.
 
Arno, it seems like it worked with the transformation tool in ModelConverterX!
Thanks for pointing me in the right direction.

The only thing I don't understand is what the "size" parameter in the object header actually does. In the SCASM documentation ( I actually read that :-) ) it is just noted that this is a radius value, but what for?


Cheers,
Mark
 
Hi,

I am not sure what that parameter does. In ModelConverterX I am ignoring it when reading the SCASM file (both the SCALE and SIZE parameters). Maybe I should use the SCALE parameter as a default scaling factor in the future.

It could be these parameters are telling the scenery engine about the size of the object, this will help for certain performance related issues.

I am not sure if the scale parameter is used by default in FS or if you still have to determine it in the reference point to determine the final size of the object.
 
I noticed if the size is wrong the objects shows up and disapears at the wrong time eg disapears when up close.
I noticed that in the cfs2 cfs library there are size mistakes that causes the scenery to jump up at you and then disapears.
 
Just a note, the current version of ModelConverterX is reading and using the SCALE parameter to scale the object.
 
SIZE is equivalent to v2 of the refpoint command... radius of the object. If it's wrong, then it behaves just like v2 being wrong in the refpoint command.

SCALE is the units multiplier that controls the actual size of the object.

Code: 
ObjID( 8E8F4969 45C8F8AD 9B46CFA4 2D65DC41 )
LibObj( PWR 0 SIZE 8160 SCALE 0.000977 TYPE 0x0 PROP 0 NAME "inf_control_tower_american" )

So... ( 0.000977 * 8160 ) equals a radius of 7.97232 ( about 8 meters). Which should be about right for that WW2 control tower. 8160 units at 0.000977 meters per unit.

Code: 
VertexList( 0
-6144.000488 0.000000 7168.000488 0.000000 1.000000 0.000000 0.031250 1.601563
-6144.000488 0.000000 -7168.000488 0.000000 1.000000 0.000000 0.526042 1.591146
6144.000488 0.000000 7168.000488 0.000000 1.000000 0.000000 0.007813 1.010417
6144.000488 0.000000 -7168.000488 0.000000 1.000000 0.000000 0.526042 1.013021
)


( 0.000977 * -6144.000488 ) = -5.002688476776 meters

Dick
 
You must log in or register to reply here.
Back
Top