Forums
Parser rewrite. Need Feedback! - 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: Parser rewrite. Need Feedback! (/showthread.php?tid=1346)

Parser rewrite. Need Feedback! - NaN - 09-23-2010

I've been working on the parser to have a more data driven car setup. See http://vdrift.net/Forum/viewtopic.php?t=1351 and http://vdrift.net/Forum/viewtopic.php?t=1378. The syntax is very much shader parser alike(will be merged) having sections and name value pairs. I've separated value pairs (damper-speed, damper-factor) to keep the syntax simple.

Code:
[aerodevice]
name = rear-wing
position = 0.0 -2.14 0.37
frontal-area = 0.05
drag-coefficient = 0.0
surface-area = 0.5
lift-coefficient = -0.7
efficiency = 0.95

[coilover]
name = front
travel = 0.19
anti-roll = 800.0
spring-constant = 49131.9
bounce = 2600
rebound = 7900
damper-speed  = 0.06 0.08 0.10 0.20 0.50 1.00 5.00
damper-factor = 1.20 1.10 1.00 0.90 0.50 0.30 0.10

[coilover]
name = rear
travel = 0.19
anti-roll = 600.0
spring-constant = 51137.3
bounce = 2700
rebound = 8100
damper-speed  = 0.06 0.08 0.10 0.20 0.50 1.00 5.00
damper-factor = 1.20 1.10 1.00 0.90 0.50 0.30 0.10

An alternative would be:
Code:
damper-factor = 0.06,1.20 0.08,1.10 0.10,1.00 0.20,0.90  0.50,0.50 1.00,0.30 5.00,0.10
or:
Code:
damper-factor = 0.06:1.20 0.08:1.10 0.10:1.00 0.20:0.90  0.50:0.50 1.00:0.30 5.00:0.10
or:
Code:
damper-factor = 0.06=1.20 0.08=1.10 0.10=1.00 0.20=0.90  0.50=0.50 1.00=0.30 5.00=0.10

I'd prefer to keep them separated. What do you think?

- cologne - 09-23-2010

Quote:I'd prefer to keep them separated.
But the logic is: Show a list of pairs of values!
White space isn´t a good delimiter for pairs of values.

Code:
damper-factor = (0.06,1.20), (0.08,1.10), (0.10,1.00), (0.20,0.90), (0.50,0.50), ( 1.00,0.30), (5.00,0.10)

Code:
torque-curve = (2000, 70),(3000, 74),(4000, 110),(5000, 144),(6000, 177),(7000, 197),(8000, 222),(9000, 253),(10000, 287)

Or without comma between brackets?

- NaN - 09-23-2010

What about(omitting the comma):
Code:
damper-factor = (0.06, 1.20), (0.08, 1.10), (0.10, 1.00), (0.20, 0.90), (0.50, 0.50), (1.00, 0.30), (5.00, 0.10)

damper-factor = (0.06 1.20) (0.08 1.10) (0.10 1.00) (0.20 0.90) (0.50 0.50) (1.00 0.30) (5.00 0.10)

Hmm, the comma delimited list looks more readable.

- NaN - 09-24-2010

What do you think about merging suspension and wheel? Right now there have to be the same number of suspension and wheel sections.

Code:
[wheel]
name = front-right
orientation = right
model = oem_wheel
tire = tire-front
brake = brake-front
coilover = coilover-front
position = 0.736, 1.14, -0.47
hinge = 0.0, 0.0, 0.0
camber = 1.33
caster = 6.12
toe = 0.0
ackermann = -8.46
steering = 30

An alternative would be to define the suspension relative to the wheel(orientation) to be able to share it:

Code:
[suspension]
name = front
coilover = front
hinge = 0.0, 0.0, 0.0
camber = 1.33
caster = 6.12
toe = 0.0
ackermann = -8.46
steering = 30

[wheel]
name = front-right
orientation = right
position = 0.736, 1.14, -0.47
model = oem_wheel
suspension = front
brake = front
tire = front


- cologne - 09-24-2010

I don´t like these named references to other datablocks. It logical, hierarchical and i use in my own programming.
But tuning a config file, it´s not convenient.
Aims: hold data together and define only differences.
Another proposal (and fast example):
Quote:[suspension-front]
model = oem_wheel
tire = tire-data....
brake = brake-data....
coilover = coilover-data....
camber = 1.33
caster = 6.12
toe = 0.0
ackermann = -8.46
steering = 30
hinge = 0.0, 0.0, 0.0

[suspension-front-left]
position = 0.736, -1.14, -0.47
orientation = left

[suspension-front-right]
position = 0.736, 1.14, -0.47
orientation = right
Like a cascading stylesheets, the more specific value - suspension-front-left - overwrites the presets - suspension-front -

- NaN - 09-25-2010

The named references are a necessity I fear. The idea is to expose the implementation to allow more flexibility. See it as a stupid simple declarative script language. I have actually considered to go towards a Lua or Python compatible syntax to emphasize this.

- cologne - 09-25-2010

NaN Wrote:See it as a stupid simple declarative script language. I have actually considered to go towards a Lua or Python compatible syntax to emphasize this.
Oh, i love deep complex hash-structures in Perl!
But the car-file is the interface to ambitious users. A programming language isn´t the best template! The car-file should simply readable and understandable.

Code:
[wheel-0]
orientation = left
...
[wheel-1]
orientation = right
...
[wheel-2]
orientation = left
...
[wheel-3]
orientation = right
...
...very impressive. Will there be a [wheel-4]? Where is wheel-1, front/rear?

Code:
[suspension-0]
coilover = coilover-front
Is "coilover-front" a reference? Why not a datatype „named reference“:
Code:
[suspension-0]
coilover = "coilover-front"
The other way round:
Why [coilover-front] and not [coilover-5]?
Is "coilover-front" a reference or a keyword? There is no different namespace!

- NaN - 09-25-2010

Code:
[wheel-0]
orientation = left

Yes this sucks(wheel is the type, 0 is the identifier/name). Will change to
Code:
[wheel] ; object type
name = front-left ; whatever object name you prefer
orientation = left

What if you wanted to describe a 2 or 3 wheeled vehicle or even a 6 wheeled one. Do you propose to have templates for every possible vehicle type, or go back to the previous 4 wheels only configuration.

I want to move the complete car declaration into the config files to get rid of the hardcoded load/init code. So there will also be scenenode, drawable, model and light objects(sections). This is going to be too much for the ambitious user I guess. Any ideas?

- NaN - 09-30-2010

Wheel graphics(rotating parts):

Code:
import xs.car

[mesh.tire]
name = fl_tire_mesh
tire = front_tire
scale = 1, -1, 1
;position = 0, 0, 0
;rotation = 0, 0, 0

[mesh.wheel]
name = fl_wheel_mesh
tire = front_tire
mesh = oem_wheel.joe
scale = 1, -1, 1

[mesh.brake]
name = fl_brake_mesh
brake = front_brake
scale = 1, -1, 1

[drawable]
name = fl_tire_draw
mesh = fl_tire_mesh
texture = touring.png
;color = 1, 1, 1, 1

[drawable]
name = fl_wheel_draw
mesh = fr_wheel_mesh
texture = oem_wheel.png

[drawable]
name = fl_brake_draw
mesh = fr_brake_mesh
texture = slotted_shiny.png

[scenenode]
name = fl_wheel_node
drawable = fl_tire_draw, fl_wheel_draw, fl_brake_draw
transform = front_left_wheel.transform
;parent = scene_node

The import directive is needed to get front_tire, front_brake, front_left_wheel objects. The scale is mirroring the mesh. We don't support scaling in the scenenodes(it would affect the normals). This means the above code has to be replicated for each wheel for a default car configuration, doh.

Looks like a lot of boilerplate code. The good thing is that it could be shared using import.

I have to admit that the readability goes down with the number of objects as you have to look for the referenced entities. Any proposals to enhance this are very welcomed. I could compile a list of objects I'd like to expose if there is interest.

- NaN - 09-30-2010

We could actually support object mirroring in the scenenodes i think. It would simplify the car setup a lot.

Code:
[scenenode]
name = fl_wheel_node
drawable = front_tire_draw, front_wheel_draw, front_brake_draw
transform = front_left_wheel.transform
mirror = y ; mirror axis, can be multiple xy or xyz

Edit:
The mirroring has to happen relative to the drawable. Means we need one drawable per wheel(but can share the meshes).
Code:
[drawable]
name = fl_brake_draw
mesh = front_brake_mesh
texture = slotted_shiny.png
mirror = y

[scenenode]
name = fl_wheel_node
drawable = fl_tire_draw, fl_wheel_draw, fl_brake_draw
transform = front_left_wheel.transform