02-28-2008, 01:23 AM,
|
|
zimluura
Senior Member
|
Posts: 286
Threads: 22
Joined: Oct 2007
|
|
AWD + custom gauges thought
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
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?
|
|
02-28-2008, 02:38 PM,
|
|
aegidian
Junior Member
|
Posts: 18
Threads: 2
Joined: Feb 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?
|
|
02-29-2008, 05:24 AM,
|
|
aegidian
Junior Member
|
Posts: 18
Threads: 2
Joined: Feb 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.
|
|
02-29-2008, 08:49 PM,
|
|
joevenzon
Administrator
|
Posts: 2,679
Threads: 52
Joined: Jun 2005
|
|
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.
|
|
03-01-2008, 04:47 AM,
|
|
aegidian
Junior Member
|
Posts: 18
Threads: 2
Joined: Feb 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.
|
|
03-17-2008, 11:33 AM,
|
|
kcid
Member
|
Posts: 136
Threads: 8
Joined: Jan 2006
|
|
Late reply, but better late then never
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.
|
|
03-18-2008, 03:15 AM,
|
|
kcid
Member
|
Posts: 136
Threads: 8
Joined: Jan 2006
|
|
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.
|
|
|