Upcoming Events

Rookie friendly WTCR sereis Weekly BMW races on Simracing.GP Weekly BMW races on Simracing.GP Other regular AC events on Simracing.GP Weekly GT3 Sprint Races on Simracing.GP Weekly GT4 Sprint Races on Simracing.GP

Racer DOF exporter plugin for 3DS Max

Messages
12
Points
0
It's the UVs that were getting me, thanks! Explains why deleting perfectly good geometry would make it export without crashing. I do cnc machining, so UV maps aren't really something I deal with much. Bad geometry that makes a gcode processor lose it's cookies, now that's familiar...

Yep, I agree that it's solid tool. As you say, don't cancel, and on my machine it sometimes doesn't like it if you try to run it in the background. All in all I'm quite impressed.

Also, how do you guys preview/check cars when you're working on them? Raven into a garage? Is there a 'carlab' type utility?

Thanks again,
moon
 
Messages
3,007
Points
0
We used to have Carlab, but it went out of support over a decade ago... which is a shame really as it was quite useful thinking back.

I just export cars and check them in Racer.

I use ASE > modeller > DOF. Mainly because I can select the whole car which can be many objects, and export them all as one DOF. I can build in cm units. Then in modeller.exe you use the /100 feature to get the model into metres.

You can combine in Max then scale down for export but it's a bit of a faff to then either un-do it all, or reload the scene pre-collapse/scale.


Also another thing to watch out for with Some1's exporter is that it doesn't respect the smooth groups, so you need to split your hard edges before export!




We need a more open exporter really, something we can all tweak/change the code to suit our needs, and that will work from old versions of Max to the newest ones using Maxscript... something I really want to do... including dummies for things like car lights, naming conventions for brake light models, and just generally fire our loads of data automagically.

Won't it be nice to just press a button in Max and have the car just update where needed :D

It's something I really want to do but for now I'm busy writing scripts that save even more time when making tracks :)

Dave
 
Messages
12
Points
0
I've had a copy of racer on one of my machines for quite a few years now, just running tracks and cars that would load up first try. Finally gave in and started messing around under the hood recently. So much fun! I'm only just getting started and it definitely seems to me that tools, scripts, and structure is the key. Starting in on a little library of well-formed template sections for car.ini and car.shd, and going thorough all my files and getting everything right and tight.

Is there documentation for the DOF format? Scripting is something I have a bit of experience with and I would be glad to contribute (if I can) to building a maxscript dof exporter.

cheers,
moon
 
Messages
12
Points
0
Duh... Sweet, thanks!

At first glance it was a bit daunting, but looked it over a bit more and it started making some sense.
 
Messages
3,007
Points
0
Just start with simple stuff... once you can output a single triangle with the correct material and UV to a DOF file, it's just looping and appending tasks mainly.

Maxscript is quite good at building binary strings to, I've done bin to hex and ascii and so on, both import and export, so that side of things shouldn't be too much of a faff.

It may not be super fast via maxscript but once you get a good robust set of functions it shouldn't really matter within reason.


I'm super busy right now but in a few weeks I should be able to start looking at this maybe.

If we start a thread and throw up snippets it could be useful. I know Camsinny is also interested, and I think Stereo is wanting to do something similar in Python for Blender maybe... and we have Some1 around who wrote the great plugin we currently use.

Between us I think we should be able to get a nice maxscript exporter working... with enough toggle switches to satisfy everyone's needs for their preferred workflows or needs at the time (ie, cars, tracks, skeleton models, whatever)

Dave
 
Messages
479
Points
0
I was thinking the other day that it'd be pretty cool to try to build a carlab type app in unity. Then you'd just have to export say an FBX and you could do all the conversion and stuff within the unity app.
Potentially you could even tweak materials and physics in it if someone was that adept at coding...
 
Messages
12
Points
0
'If we start a thread and throw up snippets it could be useful. I know Camsinny is also interested, and I think Stereo is wanting to do something similar in Python for Blender maybe..'

That sounds fantastic. The one triangle is the way, good call. The other day I popped out a DOF with the max plugin of just one triangle and been having a peek.

The unity carlab idea has crossed my mind also, makes me drool. That would be very, very cool. If we got a maxscript exporter working and the guts were thoroughly documented it would make things like porting to python for blender much less painful. I'm a rhino guy, and the scripting is python based now, so i'd be porting it that direction also. Rhino builds beautiful surfaces, but over all Max seems best tool. Things like UV mapping in rhino are pretty crude comparatively.

One caveat: I wish I could devote more time to this, but it's not an earner for me so will get worked on as and when work/life allows.
 
Messages
3,007
Points
0
I've been doing some Racer work again and it's Some1's tool that is working the magic for me.

If it just did the smooth groups, and a toggle switch to export the selection as a single DOF, or as a DOF per object, it'd be the only tool you'd ever need (ish hehe)

Some1, how about it.

I'll send you some serious beer tokens if you would be willing?

Dave
 
Messages
856
Points
1,031
So last night Dave asked me if it would be possible for me to add some functionality (smoothing groups) to the DOF exporter. Truth be told, I simply do not have the time (and have a little bit of lack of motivation to do stuff for Racer).

Still, if there's anybody around here with at least intermediate C++ skills, I can provide the source code for the exporter, so the community can keep it alive.

As for smoothing groups, guys do you really find them useful? I have never really used them extensively, and think they are more trouble than they are worth. My workflow for getting hard edges is just doing a split on a selected edge or a "detach to element" on a selected face. Usually I do not move single vertices around (always drag a selection around a vertex to get all the vertices selected even if they overlap), so detaching to elements does not pose any issues for me. Besides, rFactor tools for example, also do not support more than one smoothing group.
 
Messages
3,007
Points
0
Thanks for the kind offer Some1.

I'll have to see what I can come up with. I can't do the coding but I have a friend who might... but whatever happens the tool will be free for all, and still called the Some1 DOF exporter :D


As per smoothing, well I agree to a certain extent. Some people like it, some don't.

As long as you know what is done I see no problems. Ie, you can split by smooth groups and the smooth group data is retained, so you can weld later if you want with a 0.1mm tolerance and get the original mesh back with the original SG's.

Or like you say, just drag and move many verts.

UV editing doesn't seem considerably different either.


BUT, it's just handy to have the support there native to Max.

Long term I'd like to write a human readable type parser to sit with the exporter so we can just set our preferences.
Probably have many files with preferences.

Stuff like being able to dev for say AC, but have the exporter work and take data direct to Racer too.
Imagine all those lovely modded AC tracks in Racer with decent shading... it might at least kick-start some more interest in Racer from other modders if it's super easy to mod for in these kinds of ways.

I have no doubt for example that 95% of the AC shaders, or rFactor2 shaders, can port over to Racer without any issues at all.
I've not really seen anything super sophisticated yet to suggest why we couldn't.

Dave
 
Messages
856
Points
1,031
I have no doubt for example that 95% of the AC shaders, or rFactor2 shaders, can port over to Racer without any issues at all.
I've not really seen anything super sophisticated yet to suggest why we couldn't.
I do have a slight doubt. rF2 and AC are DirectX (and shaders are encrypted), while Racer is OpenGL.

I wonder what ever happened to Ruuds plans of moving from Cg to GLSL?
 
Messages
3,007
Points
0
Yeah the actual shader's code wouldn't transfer over, but for the most part it's pretty basic stuff in most of these track shaders.
We can easily copy the functions themselves so the behaviour is about the same.

The only real issue is stuff like TOD/lighting setups etc, but that can be done at this end.

In the end 90% of the work is laying polys and adding textures. The shading/lighting can all be re-applied appropriately for the Racer environment.

Dave
 

Stereo

Premium
Messages
4,155
Points
2,212
Yeah, I'm familiar enough with AC's shaders now to rewrite whichever functionality in Racer's cg no problem.


Actually one thing I was thinking of writing as a little tech demo is a deformed tire shader, of course without data updates from Ruud it can't behave properly (lateral/vertical tire flex distance should be enough info, maybe the current contact patch's normal - set separately for each wheel object). Like the flag shader, it's not all that complicated geometric transformation, since the wheel model origin is always 0,0,0.

On the topic of tire shaders though I do like AC's strategy of a single shader with 4 textures (base + nm, blurred base + nm) that uses wheel speed to interpolate. But again, needs data that iirc Racer shaders don't have.
 
Messages
3,007
Points
0
In theory it saves some author work I suppose.

But that is just for the tyre.

So they also expect you to have two wheel models I assume, one with the spokes, and one with a flat plane for the blurred wheel spokes part...

In Racer we can do it all with one shader in theory with excellent appearnace (if/when better cube map supports arrive)


I'm not sure what the 'in thing' is for tyres/wheels. I like the idea of combining them as it saves on draw calls, many times over many cars on screen.

I guess these days we can add enough polygons to wheels to make the tyre/wheel interface look smooth without a blended texture edge... but it still seems nice to use one shader rather than two.

With say 5 cars on screen, that might be say 20 wheels + 20 tyres = 40 batches. Many will be occluded but maybe 30 > 15 batches is a worthwhile saving perhaps?!

Dave
 

Stereo

Premium
Messages
4,155
Points
2,212
Yeah, there are 3 models - tire, wheel, blurred wheel. I've always kept the tire and wheel textures separate for no major reason anyway. I guess you could put it all in one with the right logic, eg. dedicate right half to non-blurred, then just +0.5 to UV coordinates to the left half blurred.

Actually in terms of transparency I think it's better to just have separate objects though - only the blurred rim needs alpha mixing, putting it on objects that don't need it just makes the renderer work more.
 
Messages
3,007
Points
0
I don't think it'll be long until we can do better blurring on wheels and things automatically any way.

In theory being able to do rotational types of blur can't be too far away vs the current linear types?!


But yeah, now with higher poly counts splitting tyre/wheel seems ok. You could then indeed do nice tyre related things to just the tyre.
You may as well split the tyre/wheel inputs for cars too in theory... that way you could swap wheels but keep the same tyres = cheaper on DOF mem footprint etc.


I've had no time to look at an exporter yet. Been busy scripting other stuff. Just 6hrs or so away from having a full armco generator script.
Just draw a 2D spline for the layout, a terrain to conform to, and then add the modifier to the spline.
Press a button to update, and it normalises, conforms, sweeps, textures, placing ends, poles etc etc... all very nice indeed :D
 
Messages
479
Points
0
Still, if there's anybody around here with at least intermediate C++ skills, I can provide the source code for the exporter, so the community can keep it alive.

As for smoothing groups, guys do you really find them useful? I have never really used them extensively, and think they are more trouble than they are worth. My workflow for getting hard edges is just doing a split on a selected edge or a "detach to element" on a selected face. Usually I do not move single vertices around (always drag a selection around a vertex to get all the vertices selected even if they overlap), so detaching to elements does not pose any issues for me. Besides, rFactor tools for example, also do not support more than one smoothing group.

I don't claim to be intermediate in any language, but hosting the code somewhere for the community could only be beneficial.

W.R.T. Smoothing groups - I use them a LOT. I probably should split the edges, but I haven't gotten into the habit.
I am in the habit of not drag selecting verts since I've messed up a couple of models doing that in the past (front view selecting rear bumper and not finding out until about 4 hours later...ouch)

Mainly though it's just quick and easy.

###EDIT###

Just looking at the racer DOF docs:
TVR1/TVR2/TVR3/TVR4/TVR5/TVR6/TVR7; texture coordinates, 2nd/3rd/4th etc channels. These are only supported since Racer v0.9.0.RC8 (June 2013) and support multitexturing (finally!).

Assuming we had an exporter that did export those channels (does the ASE to DOF tool in modeler do it?) Has anyone tried using a second UV channel?
 
Last edited:
Messages
3,007
Points
0
I'm still on RC5c here... but it'd be interesting to try them via the modeller indeed.

I guess we'd need to write a specific shader to load the appropriate UV channel too.

How would you load them?

Current approach seems to be...

// App to vertex
struct a2v
{
float4 Position : POSITION;
float3 normal : NORMAL;
float2 tc0 : TEXCOORD0;
}

So you'd need to set tc1 : TEXCOORD1;

But obviously all those TEXCOORD entries are used up a lot already... I'm not sure how many we can use, or how many are reserved etc etc.


So there are two tasks, getting the DOF with them, then getting the shaders to use them.

Hard to know if modeller.exe is preserving them, possibly use 'information' in modeller.exe to check?

Endless opportunities for nice features if these channels are now exposed though!

Dave
 
Messages
479
Points
0
I'm guessing a2v would be float2 tc1 : TEXCOORD1;
then in v2p you could assign it to whichever free slot you want.
i.e. if you're writing a new shader you could leave it at TEXCOORD1 or if you're modifying an existing one just add another one to the end TEXCOORDx.
However, I think we were hitting the limits already - so we may need to start packing things across channels. Depends on the shader really.
 

Similar threads

Top