.
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 41

Thread: Blender->fbx->trainzmesh problem (98592)

  1. #16
    Join Date
    Nov 2006
    Location
    United States of America, Oregon, Portland
    Posts
    3,331
     

    Default

    I doubt this is your problem, but as a future reference, one other thing I've seen cause problems is multiple UVMaps on a mesh.

    Curtis

  2. #17

    Default

    Thank you gentlemen!

    @Paul - strange, but I have 2-sided unchecked and it is default in Blender 2.79b. I also opened the blender file which I sent to you and all 3 meshes have this feature unchecked. I know the purpose of the tag and don't use it.

  3. #18
    Join Date
    Nov 2006
    Location
    Dinan, travelling around France.
    Posts
    7,965
    Blog Entries
    30
     

    Default

    Quote Originally Posted by samplaire View Post
    T...

    @Paul - strange, but I have 2-sided unchecked and it is default in Blender 2.79b. I also opened the blender file which I sent to you and all 3 meshes have this feature unchecked. I know the purpose of the tag and don't use it.
    Perhaps it got changed. There have been many Blender updates and rewrites since I started.

    Haven't looked at the Blender files yet but got the obj mesh into Blender. After adjusting the heights of the meshes, since they were underground, I added a simple tbumptex material and adjusted the UV map to suit. This is it in Preview Asset:

    arch_with_missing_bits.jpg

    The arch roof is missing as described earlier. I'll see what I can do.

    Paul


  4. #19

    Default

    I always use ‚bow’ instead of ‚arch’. I hope it is a synonym in this case... the mesh is beliw the ground intentionaly. The whole VS is to be compatible to the FMA one.

  5. #20
    Join Date
    Nov 2006
    Location
    Dinan, travelling around France.
    Posts
    7,965
    Blog Entries
    30
     

    Default

    Quote Originally Posted by samplaire View Post
    I always use ‚bow’ instead of ‚arch’. I hope it is a synonym in this case... the mesh is beliw the ground intentionaly. The whole VS is to be compatible to the FMA one.
    Well, the words refer to a similar shape - i.e a curve, but we don't use the word "bow" as a synonym for arch. Or, at least I don't. Even native English speakers have trouble with the language at times. And I was born in London!


    But I don't understand "The whole VS is to be compatible to the FMA one." although it probably doesn't matter.

    My intention is to analyse those missing faces. There is obviously something a bit different about them from the others. Plus, I also think this is relevant to the issues Majekear and I have been working on.

    Paul


  6. #21
    Join Date
    Nov 2006
    Location
    Dinan, travelling around France.
    Posts
    7,965
    Blog Entries
    30
     

    Default

    I've found something odd. If you export just the curved mesh then you will see, within TRS19, that the texture is rendered on the concealed part of the mesh. Flipping the normals on the curved mesh of the assets and re-exporting makes no difference.

    It's almost as if something is locked with regard to that particular mesh. I searched through all the attributes comparing it with a known working mesh but cannot see anything.


    I found two solutions to this:

    1. Make that mesh double-sided by setting the material metadata to double-sided. Not recommended as it effectively makes all the meshes using that material to be double sided.

    2. Join all the meshes using the same material into one mesh making sure the last mesh selected is a "good" mesh. The hotkey for that is Ctrl J. I tried it and it works.

    It bothers me that the cause of the problem is not evident and I can only assume it was introduced with the OBJ export out of GMax or perhaps the import into Blender. If I have some time I'll have another look tomorrow.

    Paul


  7. #22

    Default

    Have you experimmented with the obj or my blender project? You used only one tex in the obj first attempt you showed me. I’m asking regarding the joining. When I joined it to other elements it did no difference (it’s impossible to join it to a mesh with the same tex/material because only this arch uses it). You said you saw the texture when the arch was separated. In fact (when you go inside the model) you see it is always there.

  8. #23
    Join Date
    Nov 2006
    Location
    Dinan, travelling around France.
    Posts
    7,965
    Blog Entries
    30
     

    Default

    I was using the obj model because I was trying to simplify the problem. I wasn't aware there were two materials until I looked at the Blender project. That project uses PBR materials although I don't think that is related.

    The problem appears to be related to models built in GMax and may not be due to FBX. Take a look at this vehicle by Andi06: <kuid2:122285:502:5> GWR AEC Railcar (Single Cab) I'm sure Andi used GMax.

    There was a discussion about normals in TRS19 within the TRS19 beta forums but I can't recall the outcomes. I'll play around with this for a little longer and then I might raise the issue as a bug with N3V.

    If you want to move your project along, I suggest you remake those affected meshes using Blender.

    Paul


  9. #24
    Join Date
    Nov 2006
    Location
    Dinan, travelling around France.
    Posts
    7,965
    Blog Entries
    30
     

    Default

    I've run into a dead end with this problem. The OBJ file is in simple ASCII (no unicode) so it is easy to read the vertices information. It contains the vertices location in XYZ format, the mapping info in UVW format. the normal info in XYZ format and the identification of faces using vertex id. I'm not familiar with the UVW mapping format but it looks OK in Blender when aligned with the stone texture I was using.


    As far as I can tell the vertex normal information looks OK. A single vertex comparison of the original OBJ normal vector and the Blender data block equivalent shows they are the same values. This means nothing was changed during input.


    There are several ways to flip normals in Blender. There is the simple Mesh->Normals->Flip Normals that I often use. Within the same Normals menu you can also recalculate both inside and outside. And there is a Mesh->Faces-->Recalculate Normals that is a toggle of the Inside/Outside option. I tried all of them and, while they worked within Blender, they don't make any difference in TRS19.


    I tried something different and got some interesting results:


    1. I re-imported the obj model using the option Keep Vert Order instead of Split. This resulted in a single mesh rather than separate meshes for pillars, roof, etc. Without changing anything, I added the test material and re-exported to FBX and Trainz. The mesh showed correctly.
    2. Using the same single mesh in Blender I split off the curved roof section (P key) to make it a separate mesh. On export into Trainz the same problem appeared again. I cannot see why splitting a mesh would cause this problem. The mapping will stay the same and the normals shouldn't change.
    3. I deleted the original curved mesh and created a new one using Blender. On import into TRS19 it also had the same problem.
    4. I exported the model as XML/IM and it worked in TRS19 although the material didn't look as good with lots of highlights. So, it seems there is a rendering difference between IM models and Trainzmesh models. And I wasn't using PBR.





    In summary, you could use 1. above but you will need to stay with just one mesh and one material. It worked with the simple mesh providing but I cannot say it will work for any others you find. This would be my preferred option as it reduces draw calls in game.

    I've revised my earlier opinion and now think this is a bug and worth reporting. Since it is your mesh you may want to report it yourself. However, I can do it providing you are happy for me to provide them with your mesh.

    Paul


  10. #25

    Default

    Hi Paul, since you can explain this phenomenon in such deep yet very clear and simple way can you please report this bug? I would appreciate it. Thank you!

    Because I can’t use the same texture (the model uses a series of textures shared with other objects so merging them into one and then reunwrapping would lead to flood of other assets to be updated I’d rather stick to my workaround ie creating a box and removing all sides besides top and bottom (in this case) and front and back in the other mentioned by me asset. 16 or 12 polys more won’t ruin my models...

  11. #26
    Join Date
    Nov 2006
    Location
    Dinan, travelling around France.
    Posts
    7,965
    Blog Entries
    30
     

    Default

    Quote Originally Posted by samplaire View Post
    Hi Paul, since you can explain this phenomenon in such deep yet very clear and simple way can you please report this bug? I would appreciate it. Thank you!

    Because I can’t use the same texture (the model uses a series of textures shared with other objects so merging them into one and then reunwrapping would lead to flood of other assets to be updated I’d rather stick to my workaround ie creating a box and removing all sides besides top and bottom (in this case) and front and back in the other mentioned by me asset. 16 or 12 polys more won’t ruin my models...
    OK. I'll do that in the next day or so. I'm not sure I understand your workaround but I'll attempt to recreate it and see what happens.

    I'm sorry I couldn't come up with a simple answer although I did my best since I like a good mystery. I suspect N3V changed something wrt to the normals in the last couple of beta releases. There was some discussion about normals but I didn't pay attention.

    Paul


  12. #27

    Default

    First of all let me explain you the VS I mentioned earlier - VS standard for Viaduct System.

    My workaround:

    choose the problematic mesh, edit, „extrude (vertex normals)”, esc (so that the mesh unsticks from the mouse leaving the mesh flat but altered from a simple plane to a box but with zero height in sides), choose and delete the flat sides which look like lines.

    To make it simplier: imagine the problematic mesh is a 2 poly plane with normals to the top. When you do the command „extrude (vertex normals) to it it transforms to a box of 6 sides but you see only the top and the bottom because the rest of the sides are 0 height. However you can see the differences because thete are dots in the middle on the edges of the mesh so you can delete them as normal faces. If you do so you end up with 2 planes one on top of another and such object is visible in trainz. Of course it has 4 polys instead of 2.

  13. #28
    Join Date
    Nov 2008
    Location
    Crewe, Cheshire, UK
    Posts
    14,999
     

    Default

    Quote Originally Posted by pcas1986 View Post
    OK. I'll do that in the next day or so. I'm not sure I understand your workaround but I'll attempt to recreate it and see what happens.

    I'm sorry I couldn't come up with a simple answer although I did my best since I like a good mystery. I suspect N3V changed something wrt to the normals in the last couple of beta releases. There was some discussion about normals but I didn't pay attention.
    Normals? That might be when N3V "fixed" the normals that were showing as flipped in TRS19 but were fine in TANE and previous, see the thread on skipper1945's loco problems, apparently previous versions of Trainz were at fault? Anyway whatever N3V did skipper1945's locos all now OK. Quite a lot of my rolling stock which was done in Gmax some time ago now had the same issue, however I had fixed the normal issues in my stuff before N3V's fix came along.
    Malc


  14. #29
    Join Date
    Nov 2006
    Location
    Dinan, travelling around France.
    Posts
    7,965
    Blog Entries
    30
     

    Default

    Quote Originally Posted by clam1952 View Post
    Normals? That might be when N3V "fixed" the normals that were showing as flipped in TRS19 but were fine in TANE and previous, see the thread on skipper1945's loco problems, apparently previous versions of Trainz were at fault? Anyway whatever N3V did skipper1945's locos all now OK. Quite a lot of my rolling stock which was done in Gmax some time ago now had the same issue, however I had fixed the normal issues in my stuff before N3V's fix came along.
    A number of Andi Smith's railcars are still broken:



    I'm wondering if this is related to the flipped normals in this discussion. These traincars use Andi's liveries asset and probably Superscript.

    What did you do to fix your problem and in what 3D program?

    Paul


  15. #30
    Join Date
    Nov 2008
    Location
    Crewe, Cheshire, UK
    Posts
    14,999
     

    Default

    Quote Originally Posted by pcas1986 View Post
    A number of Andi Smith's railcars are still broken:



    I'm wondering if this is related to the flipped normals in this discussion. These traincars use Andi's liveries asset and probably Superscript.

    What did you do to fix your problem and in what 3D program?
    Ouch! didn't know about those! Got kuid's? as I can't find any of his with that problem and I thought I'd got all his stuff.

    Regarding the normals fix.
    N3V managed to get one of mine into Max and it clearly showed the normals were flipped, odd as they were not in Gmax!

    I did the fix in Gmax as that's what they were made in a few years ago now. Needed to look at it in TRS19 Preview mesh to locate the bits as normals were all showing correct in Gmax which seemed a bit odd.
    Initially I just flipped the normals, which then rendered bits missing in Gmax which was now showing the normals the wrong way, which broke them in TANE and TS12!
    So change of plan, start again detached all the offending bits and tried a Reset Xform instead, that didn't mess up the appearance in Gmax or change the normals, so then so re-attached everything and it worked now OK in TRS19, TANE and TS12. Had to do the same with the lod meshes as well and added couple more to get below the 500 Poly warning while I was at it, basically it was nearly all of my WHR rolling stock! plus had to up-version to 3.5 from 2.9 as well to upload them again, only took me a week to do 42 items...... Got there just before Early Access was released.

    Another reason to avoid Gmax I think! Just hope my Max 2010 doesn't have a similar issue!

    Edit: Just to add I can get Gmax meshes into Max or Blender however it's time consuming, so quicker to just use Gmax in this instance.
    Last edited by clam1952; January 3rd, 2019 at 08:04 PM.
    Malc


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •