CSV Object Material Problem

After re-coding my Obj->Csv Model Convertor, it does not perform correctly......
In the previous versions everything works fine, but after changing its convert behavior(From loading all faces and convert them all together to recognize "Group[g]" command and have the faces in groups)
All the faces has the same color, but I used "CreateMeshBuilder" and "SetColor" commands at the position where they should be!
I got a bit confused. Why it comes to this result? I can't understand what have been wrong!

I can't find anything immediately obvious.

Stepping it in the debugger shows that the call to GL.Color4 seems OK, but that it's not being applied; It's actually always using the values from the last material in the array.....
I *suspect* something is overflowing somewhere, but that's only a guess.

Will do some more digging, but whether this is easily findable / fixable, I'm not sure...

Edit:
I note your scale is off by somewhere around a factor of 3.
Not the issue, but it sure isn't going to be helping things....

leezer3 wrote:I can't find anything immediately obvious.

Stepping it in the debugger shows that the call to GL.Color4 seems OK, but that it's not being applied; It's actually always using the values from the last material in the array.....
I *suspect* something is overflowing somewhere, but that's only a guess.

Will do some more digging, but whether this is easily findable / fixable, I'm not sure...

Edit:
I note your scale is off by somewhere around a factor of 3.
Not the issue, but it sure isn't going to be helping things....

Yeah. According to my test, deleting all the other parts from the CSV, and left the "body" and "windowframe" groups alone, it can be successfully loaded. But if the "headlight" group is added, everything in the model became white. While changing the color of "headlight", the all other faces are all changed.
But there shouldn't be a overflow...... This just contains about 100 more AddVertex calls and about 3 more CreateMeshBuilder calls, but the old one works and the new one doesn't work!
I have used this to convert more complex models, but there's nothing bad happen!
That's a bit strange.

openGL is a state machine.

That means that anything set remains so in subsequent calls unless we unset it.


Whilst I can't find a smoking gun, some deleting of verticies and faces from existing groups seems to show that the color calls appear more prone to go wrong when there are face groups containing more than 4096 verticies.
Try limiting your convertor to 4096 verticies per face and see what happens.


As a reference note, 1.4.3 displays the same behaviour, so I'd be reasonably certain something in the openGL internals is unhappy.

Whilst marginally O/T, have you considered adding the obj parser to the main sim as opposed to building it as a standalone program?
You've clearly done most of the hard work already in parsing the vertex/ face relationships, and it should be simple enough to add, and might make things easier to debug.

leezer3 wrote:Whilst marginally O/T, have you considered adding the obj parser to the main sim as opposed to building it as a standalone program?

Well, I'll appreciate a lot if openbve provides a built-in obj support! But I think I don't have that experience and time to fork this project and then post a pull request to add this feature...... I'm not familiar with openBVE source codes(I tried to understand its structure but it's hard for me)
This convertor is a open-source project on github, while the last stable release (which does not cause this problem) 1.4 prerelease can be found there: https://github.com/zbx1425/Obj2CsvConvertor/releases

This is a semi-functional obj parser I've knocked up this morning (Object Viewer only):
https://github.com/leezer3/OpenBVE/commit/bf9f97fbabb38331a6fc64990971ed7f1503e76f

Simple stuff works reasonably well, but very complex stuff isn't so happy at the minute.
I'll try and work on this some more later in the week, but debugging large models is a PITA

No real optimization yet either, so it's taking ~20 seconds to load a 3mb model; I haven't played with your convertor, but it's not fast enough for general use at the minute.

Will merge this once it's reasonably functional.

leezer3 wrote:This is a semi-functional obj parser I've knocked up this morning (Object Viewer only):
https://github.com/leezer3/OpenBVE/commit/bf9f97fbabb38331a6fc64990971ed7f1503e76f

Simple stuff works reasonably well, but very complex stuff isn't so happy at the minute.
I'll try and work on this some more later in the week, but debugging large models is a PITA

No real optimization yet either, so it's taking ~20 seconds to load a 3mb model; I haven't played with your convertor, but it's not fast enough for general use at the minute.

Will merge this once it's reasonably functional.

That's awesome! Perfect! After having a look at your obj parser I think it's even better than mine!
I am not a professional programmer and my programming ability is poor so my program may contains many codes which don't meet te standard.
My convertor also only processes a little commands and just simply throw a warning and skip the others......

No trouble

Fixed most of the issues this morning, and made the performance a little better, but still investigating on that front. Should be somewhere similar to the B3D / CSV parser, but that's not great when dealing with 3mb + files...
Only current idea I've got is to single-thread the vertex / texture co-ordinate loading, and then to spin up multiple threads to assign the faces, but that comes with all sorts of potential issues, so I suspect not just at the moment.

The attached image is a rather oversized bridge model I fished out of a random free 3D site, which now loads correctly, albeit a little slowly.

Current limitations:

• Smoothing groups are not implemented.
  
• Ambient and diffuse materials are both just hooked into the main texture, as opposed to being separate.
  
• Specular maps not supported.
  
• Bump maps not supported.
  
• Emissive color not yet supported. (I need to find some stuff using emission and test it so I can get the half-distance equation correct)
  
• Lighting mode not supported.
  

In all three programs for this build:
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2017-10-11.zip

Will be interested to see if your broken model works OK in obj format

leezer3 wrote:No trouble

Fixed most of the issues this morning, and made the performance a little better, but still investigating on that front.

Cool. That's really faster than I thought! But I think OpenBVE is never designed to load complex models, and most of the CSV models are very simple because they're hand written.
BTW now programming a more convenient(maybe) motor sound editor which featured something like "key frames" and intent previewing......
What's your opinion for third-party developing tools?

leezer3 wrote:Will be interested to see if your broken model works OK in obj format

Unfortunately, it crashed with an Win32 error 0xe0434352 (I'm not sure with this exception id because I might misremember it.)

My testing model can be downloaded here: https://od.lk/d/MzFfMTU5ODc2MDRf/test.7z
(I hate the attach file type & size limit of this "unlimited" board......)

Fixed
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2017-10-15.zip

Issue was that the window frame group had no defined material, and I hadn't taken this case into account.
Small speedup as well relating to material usage.

I suspect this is probably at the root of your convertor's issue too somehow, as the model loads correctly.

leezer3 wrote:
I suspect this is probably at the root of your convertor's issue too somehow, as the model loads correctly.

OH GOD YOU'RE A REAL MAN!
After carefully inspecting my code I FOUND I MADE SUCH A STUPID MISTAKE!

As you can see, there are two bugs in the code.
One caused the faces to overlay and only the final material can be seen, the other caused the material binding inside groups doesn't work correctly.
After modifying only three lines of code, it works perfectly!

I nearly shouted out "F*ck"......
Anyway it works now.

The o is used by some 3D modelling programs.

All it does is to assign a human readable name to a specific group / set of groups.
Nothing interesting to a convertor or loader

leezer3 wrote:The o is used by some 3D modelling programs.

All it does is to assign a human readable name to a specific group / set of groups.
Nothing interesting to a convertor or loader

Acknowledged. I think I have my convertor done now.
What's your policy for third-party developing tools?

leezer3 wrote:The o is used by some 3D modelling programs.

By the way, there's something wrong in the Japanese Signals and Signs instruction.
In the Basic Signalling paragraph, the meaning of "Green" aspect should be "Proceed (Unlimited)" instead of "Proceed (45- 55km/h)", and the meaning of "Green Green" aspect should be "Highspeed Proceed (Unlimited, 100km/h above)" instead of "High-Speed Proceed (Unlimited)".

Oops, copy + paste typo

Michelle's documentation states something slightly different though:
http://web.archive.org/web/20120414195203/http://trainsimframework.org:80/use/drive.html

Code:

Green is 130km/h - Unlimited
Green- Green is Unlimited

Will change it to that for the minute, & will have to check the exact behaviour of the code.

Third party tools are always appreciated, although in the specific case of obj - CSV, due to the way the vertices are handled, loading the obj directly should be considerably faster

leezer3 wrote:Third party tools are always appreciated, although in the specific case of obj - CSV, due to the way the vertices are handled, loading the obj directly should be considerably faster

I am considering to make it just a backward support for older versions of openbve, BVE Trainsim, and Hmmsim, which support csv only.

I only skipped through the topic of Japanese signalisation and quite some time has passed since then; but if I still remember correctly, the exact meaning of signal aspects varies from route owner to rote owner. The sequence itself is the same, but the speed limits the aspects are assigned vary substantially.

Quork wrote:I only skipped through the topic of Japanese signalisation and quite some time has passed since then; but if I still remember correctly, the exact meaning of signal aspects varies from route owner to rote owner. The sequence itself is the same, but the speed limits the aspects are assigned vary substantially.

You're right. But it is a immediately error - Proceed green signal itself has a speed limit of 55 km/h is absolutely incorrect.