Forums
AWD + custom gauges thought - Printable Version

+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4)
+--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9)
+--- Thread: AWD + custom gauges thought (/showthread.php?tid=919)



AWD + custom gauges thought - zimluura - 02-28-2008

AWD: i'm not sure, but i think i found a work around for the awd power problem. i upped the rotational inertia on the rear wheels to simulate increased powertrain weight. seems to provide an appropriate performance loss. i could be out of my mind though Smile

Custom Gauges: saw this in the issue tracker. i would think the way to implement it would be to have a few quads (or 2 tris) on the dash as separate objects called: speedometer, tachometer, fuel, oil pressure, turbo pressure, clock, etc.
and then from there have each car get a texture (with heavy use of alpha) for these. or perhaps, if the current speedometer and hud graphics are already drawn using textured quads they could just be drawn as objects instead of as overlays. did that paragraph make sense?


- joevenzon - 02-28-2008

Yeah, that makes sense. That's sort of what I was thinking. There also needs to be some extra info per car like how far the needle is supposed to rotate, where its center of rotation should be, etc. Unfortunately I can't think of a good way to come up with those numbers except trial and error for each dashboard graphic... it'd be nice to have some sort of GUI.


- aegidian - 02-28-2008

Wouldn't it be more sensible to update the quad's texture with the needles and any digital read-outs drawn on? That way the needle is positioned automatically.

Possibly by drawing the guages to separate SDL surfaces and updating the texture from them?


- joevenzon - 02-29-2008

Quote:Wouldn't it be more sensible to update the quad's texture with the needles and any digital read-outs drawn on? That way the needle is positioned automatically.

Possibly by drawing the guages to separate SDL surfaces and updating the texture from them?

Doing rotation like that in software (if that's what you're suggesting) is quite slow, and uploading a new texture each frame is also relatively slow. Rotating a quad in hardware is super fast. Besides, it doesn't gain you anything to draw to a separate surface and then updating the texture -- you still have the problem of defining where the needle graphic needs to go and how far to rotate it, etc. The idea is that each car would/could have a separate graphic for the gauge and needle, so someone somewhere has to define where the needle graphic should go and how far it should rotate. Or have I misunderstood what you're saying...?


- aegidian - 02-29-2008

I would have drawn to a separate SDL_GL surface and passed the resulting data to a texture, BUT you could instead use two passes to the main frame buffer - which would be faster - and then use glCopyTexSubImage2D(...) to copy the rendered image to a texture.

For the car interior, it would probably fit VDrift best if the dial quads were left empty - and separate models just consisting of each dial used to fill the gaps (to work around VDrift's one-texture-per-model limit).

The .car file would have to specify any needle center offset (away from the center of the quad, and where none is specified this can be assumed to be 0,0: the quad center) and the zero and maximum (or zero and range) rotations of the needle. Plus the position and font/size of any digital read-outs. These would have to be associated with the gauge model file.


- joevenzon - 02-29-2008

aegidian Wrote:The .car file would have to specify any needle center offset (away from the center of the quad, and where none is specified this can be assumed to be 0,0: the quad center) and the zero and maximum (or zero and range) rotations of the needle. Plus the position and font/size of any digital read-outs. These would have to be associated with the gauge model file.

Right, so ... why do you say it would be more sensible to do something else?

Oh, re-reading you were probably replying to zimluura's description of how to draw the objects.

Regarding this bit:

Quote:I would have drawn to a separate SDL_GL surface and passed the resulting data to a texture, BUT you could instead use two passes to the main frame buffer - which would be faster - and then use glCopyTexSubImage2D(...) to copy the rendered image to a texture.

It's a lot faster to just draw the gauge/needle onto quads on the dash than to draw them into a texture (via glCopyTexSubImage2D or even via the faster method, FBOs) and then draw your texture onto a quad on the dash. So, basically like how the current HUD is drawn but instead of drawing them from an ortho2D modelview matrix, draw them on the dash. This isn't very different from what you're suggesting, it's just a bit faster because it cuts out the step of rendering to a texture... unless I'm totally missing your point.

Aside from the question of how to render is the question of how to specify positions and textures. My first thought is just to have separate .joe files (probably just 1 quad) for each dial, so the artist could position the dial quads in a sensible spot in a 3D app. The .car file would then specify, for each gauge, the .joe file, a texture, a needle texture, a needle position offset (where 0.0 = overlayed exactly with the dial quad), and a needle scale (where 1.0 = the same size as the dial quad). Later on we can get fancy with S2000-style digital bar-graph readouts, numbers, etc.


- aegidian - 03-01-2008

I think I misunderstood what you were suggesting - I thought you were suggesting drawing the moving parts of the displays by locating their position in space from the .car file rather than from the quads. Still I think the discussion was useful.

Sorry.


- joevenzon - 03-01-2008

No problem, I figured there must have been a miscommunication.


- kcid - 03-17-2008

Late reply, but better late then never Smile
The MI and CO for example already have gauges without textures, I can easily make seperate objects with names for them.
Isn't it more easy to start with for example a gear changing light or a box that tells you what gear you are in on the dashboard? For that there are no rotations etc needed. If you need me to build some graphic or model please let me know.


- kcid - 03-18-2008

I also got a idea about the problem we face with the rotation of the needle and different speed/rpm's of different cars. If we just texture a meter called Speed and name it as Speed in the .car file.
Then we do the math through: http://en.wikipedia.org/wiki/Interpolation Linear Interpolation. So 0 = 0 degrees and for example 100Kmh = 50 degrees and 270Kmh = 300 degrees of rotation.
Can it be done like this?
It's also done like this in the flightsimulator Flightgear. Lots of dails are made there with Interpolation.


- zimluura - 03-18-2008

i've been thinking about this a little lately. and i'm starting to think that it might be easiest to just detach the gauge graphic from the hud and draw it in 3d space. and then have some vectors for translation and rotation that get loaded out of the .car file. positioning for them isn't done in blender, it'd be done in in the game engine, with the "restart" button hit allot of times. but then the next step would just be to figure out a scheme for loading custom gauge graphics for each car (with corresponding degree/mph coordinates.

and then use interpolation like kcid suggested, though that might need to be muli-parameter in the long run as i think some speedometers are a little different down at 0-15 mph range.


- joevenzon - 03-18-2008

kcid Wrote:I also got a idea about the problem we face with the rotation of the needle and different speed/rpm's of different cars. If we just texture a meter called Speed and name it as Speed in the .car file.
Then we do the math through: http://en.wikipedia.org/wiki/Interpolation Linear Interpolation. So 0 = 0 degrees and for example 100Kmh = 50 degrees and 270Kmh = 300 degrees of rotation.
Can it be done like this?

Yeah, that's what I was thinking. In the .car file it'd have to be specified which needle rotation corresponds to which speed, and then interpolated in between.