Blender

[GeorgeCW]

The blender site now has 2.58 listed as stable. Can the material generated be used in trainz? Both 64 bit & 32 bit being listed. Been using 2.49. I am using windows 7 ult., if it can be used is 64 bit or 32 bit the way to go?
George

 

[johnwhelan]

The blender site now has 2.58 listed as stable. Can the material generated be used in trainz? Both 64 bit & 32 bit being listed. Been using 2.49. I am using windows 7 ult., if it can be used is 64 bit or 32 bit the way to go?
George

Last I heard Torsten has 32 bit windows on his machine so don't expect the 64 bit version to work with the exporter.

Cheerio John

 

[Jananton]

Last I heard Torsten has 32 bit windows on his machine so don't expect the 64 bit version to work with the exporter.

Cheerio John

Hmm, if I remember correctly I asked this some time ago in Torsten's exporter thread and was told it shouldn't make any difference. What seems logical, since the python code stays the same for both flavours. In fact, the only big difference would be the allocation for pointers to memory locations and possible max size for variables. Both allocated by python internally.

Greetings from sunny Amsterdam,

Jan

 

[NikkiA]

Hmm, if I remember correctly I asked this some time ago in Torsten's exporter thread and was told it shouldn't make any difference. What seems logical, since the python code stays the same for both flavours. In fact, the only big difference would be the allocation for pointers to memory locations and possible max size for variables. Both allocated by python internally.

Greetings from sunny Amsterdam,

Jan

Correct, since python doesn't expose pointers to the programmer, there's very little that can go wrong when a python script is developed on 32bit, but deployed on 64bit.

The only real concern is the other way - developed on 64bit and deployed on 32bit, because the python 'numbers.Integral' (aka 'int') class defaults to 32bit on 32bit and 64bit on 64bit, so if any values were routinely above 2.blah billion or below -2.blah billion, then a bug would exist when run on 32bit machines.

But there really isn't many numbers of that form that should show up in a trainz asset - in fact, I'd imagine any integer numbers will be polygon counts or things of that nature, which won't likely be too big. If there were issues with that, it would be relatively easy to fix by forcing the use of bignums (arbitary precision integers).

Since python scripts are distributed as source, it would be relatively easy to fix even if the original developer was unable to.

 

[johnwhelan]

Hmm, if I remember correctly I asked this some time ago in Torsten's exporter thread and was told it shouldn't make any difference. What seems logical, since the python code stays the same for both flavours. In fact, the only big difference would be the allocation for pointers to memory locations and possible max size for variables. Both allocated by python internally.

Greetings from sunny Amsterdam,

Jan

Sounds like real soon now I should try 2.58 64 bit then. I'll wait another day to gather up my courage.

Cheerio John

 

[hminky]

I use 2.49. What are the advantages of 2.5X for Trainz?

The guy who did the Railworks exporter stopped at 2.49 because he felt everything needed for a train sim was taken care of in version 2.49.

I find I use the same commands in both having played with 2.57.

Harold

 

[whitepass]

2.5x has a new interface, looks like a window program.