[wacampbell]

Most of us Blender users know about the upcoming 2.8 release.

First off, be advised that my current Blender to MSTS exporter, version 3.5, is NOT COMPATIBLE with Blender 2.8. We'll have to stick with Blender 2.79b for now.

But I am excited about the new release and in particular the Eevee graphics engine. I am updating the exporter to work with 2.8, but it presents some challenges.

One issue is that 2.8 looses support for Blender Game materials and for the 'face textures' features that my exporter uses. The new material system is node based, like Cycles. I support their decision. The multiple materials systems, carried forward to maintain legacy compatibility going back forever, made using Blender more complicated. But the new material system will make it harder for us in a few ways.

We'll have switch to using Eevee materials. This is good in that it gives us PBR and HDR and allows us to make content for a future Open Rails that supports such advanced materials. The idea is we will build models that look great in Eevee. And it will be the exporter's job to downgrade them to work in Open Rails using whatever features it supports at the time. As Open Rails adds advanced materials, we just have to 're-export' our models to whatever new formats develop and we'll see the improvements in the game.

With all of these changes, bringing our old models forward to 2.8 will take some effort. We'll need to create new materials for them, and reapply textures, although the UV mapping can be reused. I see us having to keep 2.79b around for a while to deal with our legacy models.

I am also revisiting how we define the LOD models. The current method with object properties is awkward and time consuming. There has to be a simpler way.

So I am open to input and ideas on changes. What are your thoughts.

Wayne

[longiron]

Wayne,

Any changes you can make to the LOD export process would be welcomed by me. The current approach is not that intuitive.

As for the new Eevee materails, sounds like a step forward but not without some pain to bring forward. I wholeheartedly support your efforts, without which I would be still struggling with TSM.

Thanks for the heads up and contribution.

chris

[Hamza97]

Hiii..., Sorry for bump.... :sweatingbullets:

@Wayne

I am onboard for the new exporter.... :D

Quote

We'll have switch to using Eevee materials. This is good in that it gives us PBR and HDR and allows us to make content for a future Open Rails that supports such advanced materials. The idea is we will build models that look great in Eevee. And it will be the exporter's job to downgrade them to work in Open Rails using whatever features it supports at the time. As Open Rails adds advanced materials, we just have to 're-export' our models to whatever new formats develop and we'll see the improvements in the game.

Seems okay.... :sweatingbullets:

Quote

I am also revisiting how we define the LOD models. The current method with object properties is awkward and time consuming. There has to be a simpler way.

Ohhh very grateful you bought this topic... The current system is little time consuming ... I could suggest that if possible we MAY can adopt system used by Railworks LOD system as some of you may know about it. We can directly name the different parts of object in fixed manner like say "handrails_500" or something similar where 500m is max LOD distance for that part.

[wacampbell]

The bump is welcome - I was hoping for some discussion.

Hamza97, on 23 May 2019 - 10:21 PM, said:

... I could suggest that if possible we MAY can adopt system used by Railworks LOD system

This is already supported in the exporter. See the last section of the manual. In fact, I build all my models using this method so I can export to both MSTS and Railworks from one source file.

[Hamza97]

Whaat.... !! :jawdrop2: I will definitely check it then.... :shock6:

[pwillard]

*** Bump ***

Any updates?

It's getting to the point where 2.8 is becoming the de-facto standard.
(IE: The "junk I forgot everything again... let me revisit my blender course material" website I use just upgraded the course material to 2.8)

Oh, and thanks... I don't want to sound ungrateful. Still using 2.79.

[wacampbell]

pwillard, on 10 July 2019 - 04:16 AM, said:

Any updates?

I haven't got started yet. 2.8 hasn't officially been released so I still have time :-)

[wacampbell]

I have been experimenting with alternate ways to specify LODs in 2.8 and haven't come up with anything brilliant.

The 2.79 msts exporter has two methods to specify LODs.

1. Adding DMIN and DMAX custom properties to an object to specify what distance range it is visible.

2. Using Railworks naming which encodes the view distance into the object name, ie 1_0100_DetailPart.

The first one is annoying, mainly around the many keystrokes it takes to create the properties, and the info is hidden deep in the object panel.
The second one is what I use mostly.

I did some experimenting using Blender 2.8's new 'Collections' feature. Perhaps having a collection named MAIN, with the next level specifying the LOD distances, eg MAIN_0100, MAIN_0200, MAIN_2000. You assign an object to one or more of these distance collections to specify what visibility that object has.

 Image1.jpg (28.17K)
Number of downloads: 4

Once I got down to testing some use cases on the 'Collection' method I wasn't hugely excited. It is sort of like method 2, ie move objects around in the hierarchy to assign LODS. But the naming isn't the same as method 2, so its not compatible with Railworks. And any new method just adds to the complication of bringing existing 2.79 models into 2.8.

I am leaning now to not making any change to the LOD method, or perhaps just going with method 2 since it is somewhat universal and abandoning method 1.

Does anyone have any thoughts or comments?

Wayne

[longiron]

Wayne,
Not a Railworks user, so this is from the MSTS/OR perspective. I found Method #1 not intuitive and took a while to wrap my head around it. I support Method #2 as the universal exporter approach. It seems straightforward and if it works for all sims - so much the better.

[Hamza97]

Yes.... I agree wit above.. Method #1 is cumbersome. Method #2 is probably best. Also, IMHO, It would be cool to have little more performance improvements... ^_^ :jumpy: