I wondered if there is some LFS track conversion in some sim, if i am not mistaken, there was a Blackwood in NK Namie, but maybe i am tripping..
Anyone did one for rFactor? How hard is to convert an LFS track, can you do it like say GP4 track to rFactor, or it is somehow protected so you have to do the "guessing" of the data?
there was the bl for namie and i believe thats it
converting the track lookwise is realtively simple with the smx files but im not sure if they contain the actual driving surface so that an issue youd have to work around
iirc the only track the devs allowed to be converted was the old s1 blackwood
Stu (Madcowie) created a Blackwood Rally-X.. it's not quite the same, but close enough... and I have a basic track layout of Westhill modelled (but unlikely to be finished seeing as rF was never more than a poor beta release).
Converting them isn't an option unless someone was to write a SMX->3DS importer or similar AFAIK. If it was possible to get the meshes into 3DS, it'd be a simple task to get them into rF, couple of hours work or so and a few more to do the AIW / cam files. Longest part would be creating bump / spec maps for all the textures.
As for the Blackwood in nk, there's an old version of the BL1 mesh around, but it's untextured and has no texture coords either, so you'd have to map it completely and seeing as it's already built, it's a PITA using spline mapping for track corners etc.
There are some versions for GR, but as seen as it's not a matter of converting the track, just recreating it in 16 colours, choosing the right objects and creating the hmap to built the mini-me of the track. GR forever
Ok, let's not go that way... "i did a Tetris version of BL"... , but that GR seems interesting, gotta try that BL
Anyway, i didn't understood the part of devs only allowing S1 BL for conversion... since when the moders asks for permision to convert a track from sim a to sim b?
So, the easy part is to convert a shape of the track, but you can't get the surface to be the same?
I already have made an SMX to 3DS convertor, but there are two problems. One is that SMX does not contain any texturing information, the other is that of licencing.
GR is great - chuck it on a memory stick, get a tonne of real tracks and cars and it would be half the size of your LFS install - if one PKlites the exe and deletes the other sound packs and so on you could fit it on to a 3.5 in floppy
No idea where it actually originated from, but I grabbed a copy a loooong time ago when RSC was still LFS' "official forum".
As for asking permission, any _respectable_ modder does.. which appears to be the minority unfortunately.. but in regards to LFS, it'd be silly not to as when I asked about converting the cars, I was told providing I gave proper credits and a URL reference back to the LFS site, there was no problem (is also stated in the readme of the CMX viewer which I didn't know at the time). Naturally giving the proper credit isn't a problem, or shouldn't be
By what Becky has said above, it sounds like she's got the same results as the old BL1 mesh available... a single mesh for the entire track, with no textures or mapping coords.. so getting the actual track into rF for example would be pretty easy if you just used a single texture for testing.
To do it right, you'd have to go around the entire mesh and break it up into smaller meshes.. track sections of maybe 100 metres and whatnot, depending on poly count in the vacinity.
You'd then have to UVMap the entire collection of meshes and apply relevant textures.. for rF, this means 3 shaders for each material, 2 of those shaders (DX8 and DX9) containing at least 3 textures each.
Now you can export the meshes in GMT format and create a .SCN file and load into rF.
The "driving surface" I can only assume meant what determines grass / tarmac / sand etc. If so, this is easily done with rF's track .TDF (terrain) file.. so you'd name your tarmac material as 'ROAD_01' and grass as 'GRAS_MAIN', sand traps as 'GRVL_DEEP' etc etc. These will then match up to the entries in the .TDF file and rF would use those to determine what kind of surface you were on.. it's all determined by specific material names (tarmac is prepended with 'ROAD' by default, so you can use ROAD_01, ROAD_STREET, ROADWHATEVERYOULIKE yada yada). All pretty simple stuff really.. just time consuming to do it right
"No texturing info" includes lack of mapping coords too Becky?
I took what I decided to be the "easy route" for recreating them.. grabbed the large track plan views that a few people have uploaded here, mapped them to a plane below the surface height I wanted and started adding polys using the track image as a blueprint of sorts. I guessed it would be quicker and easier to rebuild and map as I go than trying to map around corners of a single pre-built mesh. I've done it in the past to fix errors / minor changes, but wouldn't fancy doing it for the majority of a track
hmm, not sure I follow that.. I thought the track polys were the drivable surface.. they certainly are in rF / GTR2 etc.
When I build a track from scratch (using example figures), I start with a 10x12 (length / width) metre plane split into 16 polys. That's my tarmac area. I then extrude width ways and create an extra 2 or 3 rows of polys for the grass. I then map the polys with the respective materials. Using the array tool, I clone the plane 10 times to create a 100metre length and weld the required vertices to create a single mesh. I then clone again as I need and apply a bend modifier to create the shapes and once the loop's complete, use an FFD box for elevations.
I can now export the say.. 30 100metre lengths of track as GMT files.
Providing my tarmac and grass materials match up with the respective entries in the TDF file.. I can now drop the meshes into rF along with a SCN file so it knows what meshes to load and bingo! I'd have a drivable track.
The same is for conversions, except the polys are already in place. The only time I ever use splines in track modelling is for adding curbs as I normally select the edges where the track meets the grass where I want the curbs to be, clone them as a spline. Create the curb as a plane and map it.. then use the created spline as a guide to position the curb.
All driving is done on the polys which I suspect to be the same in LFS too as there's a gap in the mesh on most Aston tracks (where the National config I think turns right off the start / finish "straight").. you can see it as a white line from a distance.. but if you drive over it very slowly with hard enough suspension, you can feel the car hit a "bump" as it finds the edge of the polys. I maybe wrong obviously, but I got the exact same car response when I had some gaps in my first ever track attempt for rF.
Strange as I can produce the same effect in rF / GTR2 too by making the tyre radius size in the TBC file bigger than the actual mesh / coords as the mesh is graphical only and the TBC file actually affects the dimensions there.
You'll find a lot of queries on rF forums from new modders asking why the tyres are either sunk into the ground or appear to be floating because they just copied an existing TBC file but have modelled the wheels a different size.
Again I don't know if LFS works on a similar principle but would imagine it does in some way or other. Having the cars drive on "invisible polys" (splines are just lines, so I wouldn't have thought they'd be used else it'd be like a train or Scalectrix ) would be a pointless resource hog as it'd require twice as many polys for the entire track for no reason.. one reason GTR2's wet look tracks (if you can believe that effect is meant to be wet looking ) is such a performance hog is the reflection is created by a duplicate of the track polys, but raised by 2mm or similar.
They certainly appear to be whenever I do create them, or import things as a spline, such as vector images until I convert them to a plane.
You don't have to draw / model every little bump on a track either.. you think I sit here creating manual bumps for washboard effects for my own tracks? That said, it'd explain why all LFS tracks are almost as smooth as a baby's arse and why cars float on the blackwood back straight as they go down the slope instead of looking like gravity is at work.
Can't say i'm 100% sure either way on that, I dont think it has UV data, but i'm about as sure as a broken rope bridge over a big canyon in the middle of an earth quake.
hmm, don't suppose you could send me one to have a look at could you, please?
I've got no interest in putting it in any game or anything of the sorts (have long stopped messing with rF as it's crap and ISI are liars).. and even if I did, I'd ask for permission just as I did about converting the cars.. I'm really just curious as to what you can actually get from the SMX meshes in that respect and I guess might be cool to try and use a section for a personal render or 2 if some info was still intact
I could make a 3ds, but the problem is that the information in the 3ds is what I put in the 3ds, not necessarily what is extractable.
According to this though: http://www.lfs.net/?page=CMX - the POINT BLOCK which is contained within the OBJECT BLOCK appears to contain UV format data in the CMX, whether they are all 0's or not in practice I dont know - but it looks promising.
Ahah.. thanks for that info Becky.. I guess I should have read the SMX format myself a little better (graphics coding is something I've never really looked into yet, so have skipped over a lot of the actual 3D things).
In this case then, it seems converting a track would be a lot more hassle than rebuilding it. I guess the only useful thing in this regards then would be to use the SMX mesh as a guide / "blueprint", advantage of using a mesh over a track map as I started to would be you'd see elevations / cambers much easier if you wanted to do a better job of replicating it rather than driving and trying to memorise by feel alone.
Thanks again for the info.. normally I'm pretty good at RTFM.. but I guess I severely overlooked reading what I needed to in this case
