AddATex View Facing TS2017

[mksmitht]

Been busy with TS2017 and 3dsMax 2016 adding objects for my own use that will help me develop my own route (near future) simply as a learning experience and personal hobby. Have a number of street lights and spot lights and wanted to add a glow around the bulbs. Went to the web, went through Derek Siddle's tutorial pages and tried AddATex following his examples. Was able to translate everything from Max 2009 (one used in his blogs) to 2016 (the one I am using). Everything works until I turn on view facing with AddATex. The objects (a plane--editable mesh [also tried editable ploys] centered on the appropriate axis) assigned AddATex with view facing on simply disappear. Everything else remains as is. With view facing off--I get the desired results--but obviously the glow does not rotate and looks weird from oblique angles. So tried BlendATex as an experiment to see if view facing broke in that--it did not. But BlendATex is a blending alpha, not additive alpha, so I do not get the lighting feature I want. Also tried TrainViewFacingUnlit which does work with view facing on but found that transparency there was absolute--at least in what I tried the alpha had to be either black or white with the transparency flag on--any shade of gray in the alpha resulted in the image disappearing. I can get some nice effects using TrainViewFacingUnlight for a light glow except the plane is solid--I cannot see through it as I can with AddATex.

So spent quite some time looking at other XML files especially in newer purchased routes to see if the option simply didn't work anymore with newer releases of Train Simulator (and to insure that it wasn't something in my graphics card setup that was misbehaving). Based on my work with the XML in the geometry files and taking a close look in TS2017 viewing those assets, AddATex used with view facing turned on works--looking at assets that appear to use that shader I can see the plane rotating to view and in most cases the geometry files show a simple 4 vertex quad assigned to that particular shader. I believe that AddATex with view facing on translates to PrelitViewSpaceOffset with FrameAlphaMode as ALPHA_MODE_ADD. Again I found a number of examples in newer routes using that option associated with lighting objects. Even tried changing my own object geometry XML files to match some options in those with no success.

So went through web and forum searches and found various answers--one that comes to mind is that AddATex with view facing "broke" in TS2015. Not sure I agree with that--I can see it working in other recently released routes in TS2017. Makes me wonder if what "broke" was the export process from Max to the IGS file. Or I wonder if I am missing something in my Max object that AddATex needs for view facing (though the same object will work just fine with BlendATex with view facing on).

That leads me to surmise that (1) I am missing something obvious (probable); (2) the export process for the AddATex shader with view facing on is broken; or (3) there is something missing in my 3dsMAX object required to allow the shader to work correctly.

For the record--TS2017, 3dsMax 2016 EXT2 (I have not upgraded further as I am frightened I'll break something else in the RWMaterial process), RWMaxPlugin Build Version TS2014 -v43.2a (only one that will work with the version of 3dsMax I am using) from the ~\RailWorks\Dev\MaxPlugins directory. Computer has more than enough horsepower--10 CPU's overclocked to 4 GHZ, 64 GB RAM, 2 GPU's, SSD. I don't think it's a computer issue--existing assets seem to display a view facing additive alpha plane just fine. What won't work are my attempts at recreating a light glow using AddATex with view facing on. Takes me back to the export or the object.

Insight and help appreciated. If I have missed something obvious or another resource, apologies--just point me in the right direction.

[Hack]

Sounds like you've got things right, Matt. I'll send a PM.

[dick8299]

Sounds like you've got things right, Matt. I'll send a PM.

There are more memebers that would like to know the answer, so rather than a pm, please reply to the thread.

[Hack]

Matt appears to have done everything right, so rather than ask him stupid questions, I thought it best to send him and example. Part of the answer may be contained within the 3DS Max file, which I don't normally share, but sent to Matt to help him work through this. I'm happy to share techniques with the community, but not my files, hence the reason for the PM.

Take it or leave it.

[mksmitht]

Sounds like you've got things right, Matt. I'll send a PM.

I was rather hoping someone might have posted and said this was an easy fix and here it is. Oh well....

So teaching myself the syntax of geopcdx files and found a good example of a file using what I think is AddATex in a production route (which uses an .ap file which is even better because I can easily start over [besides my own backups] without refreshing the entire simulation--and I did remember to move the .ap file so changes I make are tracking to the original object).

I am setting the production geopcdx file to have the same options as my own and I have not been able to break it yet--even to the point of changing texture options, vectorparams for ambient, emissive and specular. Checked the array indices in my file versus the production one and while obviously different, start and array boundaries all match up. Looked at the SourceLtoPTransform section as well as the bounding spheres. Production file and my file still work out.

And I can change the production from ALPHA_MODE_ADD to ALPHA_MODE_BLEND with expected results! I even substituted my own texture into the production file by getting a BMP from the production tgpcdx file, using Photoshop (I have a licensed copy) to recreate a 128x128 texture and with the NVIDIA plugins exporting to a COL_888 file (original format used in the production example I am working with) and it all still works. Even used ACE files--works too. So the exporter will understand .dds or .ace files. But it all works in the production example, and still will not work in mine.

So given the above, I think I have excluded the NVIDIA dds plugins and the exporter on the texture side. I keep ending up back at the vertex buffers and index buffers used in the geopcdx file. That one may be a dead end though I have dusted off my HEX and binary knowledge and am looking through this (and hoping sincerely there is a simple fix staring at me that I haven't seen yet).

Any other ideas welcome! Thanks all.

[dick8299]

My suggestion when all else has failed, is send a PM to Derek Siddle via the Railworks America Forum (http://railworksamerica.com/forum/index.php).

When I first started using 3DS Max and had trouble exporting a simple object as a test, Derek was very helpful and spent two hours of his own time communicating with and helping me get on the right track. It seems that Derek is very interested in helping amateur content creators be successful in their endeavors.

[mksmitht]

My suggestion when all else has failed, is send a PM to Derek Siddle via the Railworks America Forum (http://railworksamerica.com/forum/index.php).

When I first started using 3DS Max and had trouble exporting a simple object as a test, Derek was very helpful and spent two hours of his own time communicating with and helping me get on the right track. It seems that Derek is very interested in helping amateur content creators be successful in their endeavors.

Thanks much for the suggestion. I had to create an account over there and did post the same type of question. No replies yet.

However, with help I have received here, I think I figured it out, at least in the .geopcdx file. I have developed a method to get AddATex view facing working with my version of Max (2016 EXT2) and the Max plugins provided in the game. There may be an easier way to do this or an option that needs to be chosen in Max that will do the same, but at least I have something that works.

My explanation follows.

I went back to the production files in purchased routes and in the material kindly provided here (which saved hours of time in getting the pattern diagnosed) all of which used AddATex (in the .geopcdx file it's changed/aliased to PrelitViewFaceOffset). I then took my file's blob for the plane defined in the vertex section, assumed these were Hexadecimal digits, and converted the entire thing to binary, and took files that worked and converted the vertex data associated with planes using AddATex view facing to binary as well. I put binary versions, mine and the production ones, lined up one above the other in Notepad and went looking for a pattern--it was there, just took me a while to see it. But interestingly enough it's not on a binary boundary (which I am used to working with in my day job) nor does it seem to involve the majority of the blob, which is what confused me a bit at first.

The 128 sized blob section for the 1m x 1m plane using AddATex breaks down into 4 lines, 64 hex codes (again assuming these are Hex) each line. Each grouping of hex codes are separated by white space in the .geopcdx file making it easier to follow. Here is the blob from my .geopcdx file that does not work--produces an invisible plane using AddATex view facing:

0000000000000000 00000000000000BF 0000003F000000FF 0000000000000000
0000000000000000 00000000000000BF 000000BF000000FF 000000000000803F
0000000000000000 000000000000003F 0000003F000000FF 0000803F00000000
0000000000000000 000000000000003F 000000BF000000FF 0000803F0000803F

In the production files where the plane is centered, there is a consistent difference in the Hex codes in the 3rd group on each line--the 6 Hex 0's in my file are instead F (for those not familiar with binary/hex, F base 16 is 1111 base 2). When I change my blob for just those digits, it looks like the following:

0000000000000000 00000000000000BF 0000003FFFFFFFFF 0000000000000000
0000000000000000 00000000000000BF 000000BFFFFFFFFF 000000000000803F
0000000000000000 000000000000003F 0000003FFFFFFFFF 0000803F00000000
0000000000000000 000000000000003F 000000BFFFFFFFFF 0000803F0000803F

You can see that in each line, in the third set of 16 hex digits, 6 digits changed from 0 to F. And that is the only change I make to the .geopcdx file, which then seems to get AddATex view facing working. Color rendering may not be the best, but I can live with that as long as the view facing does work.

Something like RW Tools helps greatly here. There are some caveats to using this:
1. My plane using AddATex is the only object in the entire model using that shader with view facing on. I found that the .geopcdx files group the vertex sections together based on shader. Multiple objects using the same shader get lumped together. This won't work if such is the case. The blob in question should be sized at 128 in the .geopcdx file if it's the only one using AddATex view facing.
2. My plane is 1m x 1m square. Have not tried other sizes, so this may or may not work with other sized planes or those that are rectangular but not square.
3. I define my plane as an editable mesh, centered on the XYZ origin, with the pivot point of the object in the exact middle of the object. My planes are all aligned with the X axis (all vertices in the plane have Y values of 0). I have varied the height of the plane (the entire object itself) above the ground with success.
4. Have not tried the _night with this fix yet so hope that does not break this. Otherwise my lights may glow in the day.
5. The object does seem to work correctly with the alpha in the texture. So a very subdued alpha yields a subdued glow effect.

Thanks for everyone's help here with this. Hopefully others with later versions of 3ds Max using the provided plugins will be able to use this. And hopefully, someone will have an easier way to fix this involving either Max or the export from Max.

Thank you again!

[mksmitht]

So took what I discovered above (I have condensed to one line for each blob) and started to see what those bits appear to do.

First line of my original file that does not work:

0000000000000000 00000000000000BF 0000003F000000FF 0000000000000000

First line of my original file with the alteration that appears to work:

0000000000000000 00000000000000BF 0000003FFFFFFFFF 0000000000000000

I started flipping bits around. Turns out that they seem to control the color of what gets rendered in game. So if I substitute FF0000 for the FFFFFF I get a plane that is view facing but with a different shade of color than the texture file I used. If I use 00FFFF I get another color shaded--but still view facing.

My conclusion is that turning these bits on then turns on displaying the color/texture and perhaps even the alpha of the object. Perhaps may even be working with the vertex color and/or alpha of the object itself. It appears that with those all 0, I ended up with an invisible object! Was probably working, just nothing got rendered (sort of like the Invisible shader) so I could not see what I had built.

With the FFFFFF alteration, the object appears to respect my texture file--changing only the texture file color or alpha works. I also found that it worked for different sized planes, and it worked for different location of planes off the xyz origin in 3ds Max. The change also appears to respect the _night add (will only turn on at night) and also works in LOD's.

So the alteration I made seems to be turning on how the object displays, not how it is oriented in game. I have no idea what the other bits in the blob control that my export results in 0's. Other assets that I have downloaded as payware do not have those same bits as 0 so I suspect those control other important aspects of how the object displays or may be the result of different versions of the Max plugin for Railworks. Without source code, that's the best I can do at this point and the only conclusions I can draw are those I see rendered in the game. So my guesses may be off. And this may not work outside of my own environment.

That means this may not work outside of 3ds Max 2016, EXT2 where I am using the RWMaxPlugin2015_x64.dlu (that is the way I have things set up on my computer--a different setup may not work at all and in fact this may break things). May also break with a new release of Train Simulator. For myself, I'll cross that bridge when I get there. If the plugins ever get updated, I can almost guarantee this will break--I may no longer need to do this, or I may no longer be able to. And I use this ONLY for objects I create that use AddATex view facing--AddATex non-view facing works right out of the export so I don't need to alter the .geopcdx file at all to get what I want.

So if you choose to try this, do so at your own risk with the above clearly understood. I only use this on objects I created (don't need to on the others) and I would recommend that before changing your .geopcdx file you back it up! Do back that file up, so if all else fails you can put it back as original and start over. Again, do back up that file (I always back up my files to a location separate from the game folder whenever I have to revert to changing the xml code because nothing else seems to work). That way, if you change something that affects hundreds of objects you placed in your route, if it breaks you have a place to start over easily by restoring your backup file to the production location. Also, if your export does NOT have those 6 digits as 0's, I advise extreme caution before changing something--your export may be closer to working than mine and simply need a change in the Max object or export method.

Finally, I have no idea what level of complexity this adds. I am using a few lights in a test route. Using this for hundreds may kill frame rates, so again, I advise extreme caution!

My head hurts from all the binary comparison work. Takes me back to my days of working with OS or application dump files to try to see what broke by looking at machine code and memory addresses and address pointers.

I certainly hope I can find a more elegant solution using Max and approved API's for these objects. Who knows--could also be an interaction with a Windows program installed (such as the redistributable C++ or .Net) that requires a certain version for Max and the plugins to work correctly. Ideally getting things correct in Windows/3ds Max and plugin/shader use would be the goal so that changing the .geopcdx file itself can be totally avoided. And of course, if that can be done, documenting what is done is just as important so that others have a way to easily get the same result.

For now, though, only for me, because I can simply find no other alternative, I have chosen to adopt this approach so that I can at least use a few AddATex view facing rendered planes to put a nice touch on the lights I have created.