Any idea why the TRK might appear transparent in game, not rendered in TrackED but looks OK in Mapviewer?
Tried all sorts but the occurence appears almost random between builds
Quote from: h106frp on April 16, 2017, 01:36:07 PM
Any idea why the TRK might appear transparent in game, not rendered in TrackED but looks OK in Mapviewer?
Tried all sorts but the occurrence appears almost random between builds
If you haven't got an alpha on the track texture/s then I would try totally deleting the shader/s for the track surface and create a new one/s as appropriate. It's done this in the past to me too and if all other solutions fail this is what I do to solve it and it always worked for me in the past. I'm still not sure what causes the transparent shader issue at times but it's a pain in the butt when it happens. ;)
Hawk.
OK, i will give it another try - about run out of patience with it >:(
Removed all shaders - problem persists >:(
Visible in mapview but not tracked ???
Compiled using 2010 64bit plugin
Quote from: h106frp on April 16, 2017, 07:41:00 PM
Removed all shaders - problem persists >:(
Visible in mapview but not tracked ???
Compiled using 2010 64bit plugin
Can you PM me a link to the track files H, I'll have a look and see if I can see any issues. ;)
Hawk.
Will do, definately connected to TRK... declaration, same material/texture/shader declared as OFF_TRK... displays OK.
Starting to think its an exporter bug rather than the (admittedly large) model.
Seems to effect TRKASPH (B and C), TRKKERB, TRKCONC but not TRKGRAS, TRKLINE, TRKSOIL
OK, so I built another track, similar geometry and textures - compiles fine with standalone fbx2edf
Using Max2010 and the plugin - transparent track
Any idea which settings I should check in Max as this is obviously the problem
Thank you
OK, delving deeper I noticed its any surface that is marked green in TrackED surfaces that is effected ie asphalt and kerbs
Renaming just TRKASPH to OFF_TRKASPH makers the texture normal (visible) for both asphalt and kerbs, it also compiles in about 1/5 of the time
So can I discount any issue with mapping, texture and normals?
The track surface is quite heavily triangulated, would this create any particular issue for the convertor? Using 64bit 3ds plug in.
Thank you
How have you named / grouped the objects in blender?
Everything is named OK and I avoided doing any clever pivoting or grouping. Strangely the track compiled using OFF_TRKASPH is rideable, has bike shadows and gives lap times, weird!
I am using an original .trp in the track folder that was created using TRKASPH so I get a green surface - that might be why it rides - if this is a workaround then I am a bit happier. From what I have observed TrackED lifts its graphics from the .map - so I seem to have an invisible object TRKASPH and a visible OFF_TRKASPH in the same place at the same time due to the seperate compiles. Must be something clever I can do with this ;) ;D
Just to confirm, building .trp and .map correctly gives the transparency issue :(
Quote from: h106frp on May 03, 2017, 05:41:29 PM
Everything is named OK and I avoided doing any clever pivoting or grouping. Strangely the track compiled using OFF_TRKASPH is rideable, has bike shadows and gives lap times, weird!
I am using an original .trp in the track folder that was created using TRKASPH so I get a green surface - that might be why it rides - if this is a workaround then I am a bit happier. From what I have observed TrackED lifts its graphics from the .map - so I seem to have an invisible object TRKASPH and a visible OFF_TRKASPH in the same place at the same time due to the seperate compiles. Must be something clever I can do with this ;) ;D
Just to confirm, building .trp and .map correctly gives the transparency issue :(
Could you please upload somewhere the files with the transparency problem?
Hello PiBoso,
I have sent a PM with the link to the files.
Thank you for offering to assist in reviewing the files as I have just about exhausted everthing I can think of.
Unfortunately there is no easy solution.
It could be possible to rewrite the data format to use less memory.
However it would take a lot of time. An easier, quicker and more future-proof alternative is to create a 64bit version of the whole pipeline: exporters, tools, GP Bikes.
"Quicker" doesn't mean it can be done overnight, though :(
Future proof is best. The tools have worked up until recently but with larger tracks and more detailed bikes they are showing their limitations...
Understandable that it will take time but it will pay off when done! Especially a 64Bit Core engine.
Quote from: PiBoSo on May 04, 2017, 10:05:56 PM
...... is to create a 64bit version of the whole pipeline: exporters, tools, GP Bikes.
(http://media.giphy.com/media/80oGK8caBYK4w/giphy.gif)
No more LAA HACK 8)
Quote from: PiBoSo on May 04, 2017, 10:05:56 PM
...... is to create a 64bit version of the whole pipeline: exporters, tools, GP Bikes.
(https://www.rover.com/blog/wp-content/uploads/2015/08/tiny-dog-grin.gif)
Thank you for looking at the problem and noting your comments I decimated the track surface to about 40% of the original geometry and it compiled. I assume this issue applies to the size (total of geometry and texture) of a particular object group type as the total track folder size is smaller that some others that have been tested.
In the meantime could the compile log window just include a comment that memory boundaries have been exceeded, compile failed on object xxxx?
I must agree, a 64 bit version is probably long overdue, and I cannot imagine that anyone who is serious about modern PC gaming (or would be interested in purchasing a license anyway) would still be using anything pre-win7 which most likely means they are 64bit OS as well due to the realistic need for >4GB of system RAM for a decent windows experience.
Generally people are expecting high resolution textures and the full use of shaders these days - this rapidly consumes the available resources of an OS limited to allocating 2 or 4GB of application RAM.
With the multitude of different modelling suites being used I would suggest that the standalone fbx2edf should be developed to be fully featured supporting all the possible graphic abilities of the game engine.
+1 to the outcome of this.. Well worth doing even if it takes a while.
GPB has the potential to become the all-time best bike sim on the market, so a HUGE +! from me - the extra effort will be worth it's weight in gold for the future of the sim!
GO 64-bit, GO!! ;D
Please make it 64-bit, Piboso.
Quote from: CapeDoctor on May 09, 2017, 08:07:32 AM
GPB has the potential to become the all-time best bike sim on the market, so a HUGE +! from me - the extra effort will be worth it's weight in gold for the future of the sim!
GO 64-bit, GO!! ;D
Potential? But it IS the best bike sim. Well, MX Bikes too, but that's mostly the same thing... Would be nice to actually make them into a joint sim, just like WRS supports both circuits and rally cross. Maybe by the means of DLCs or something like that.
MX Bikes has the sag testing in the garage which GP Bikes lacks, so I think that might also help with that.
QuoteGPB has the potential to become the all-time best bike sim on the market....
Quote from: passerBy on May 09, 2017, 05:10:16 PM
Potential? But it IS the best bike sim.
Quote
lol, yes, it is, but the important words i wanted to convey are ALL TIME BEST...... ;D
Quote from: CapeDoctor on May 10, 2017, 04:56:39 AM
lol, yes, it is, but the important words i wanted to convey are ALL TIME BEST...... ;D
Well, neither GP500, nor even SBK2001 were close, and on the MX side of things MX Simulator is as good as gone (and it wasn't too good either), so that makes this the all times best sim, I guess 8)
You probably meant that GPB/MXB should become more polished and start leveraging 64-bit support, switch to DX11/DX12... I would agree with that :)