Login

zimluura · 02-11-2011, 11:30 AM,

http://8927818099641897009-a-18027447737...ift/trucks and cones.jpg

the road cone took no time to make - baked a normal map too. 60 triangles.

the most detailed truck in the center took longer. and is ~250 triangles i think. but all the other ones can be built by taking parts off of that one. and they all use the same texture. in the process of re-doing them so i can have an ant-eater style also use the same texture. the mirrors are done with alpha channel, which may be a no-no, but maybe not if i can join them to the mesh last (so they're always draw last, but idk, do vbo's work that way? would blender or the .joe exporter observe that?).

== things i've been contemplating
tree's are probably the most prolific thing to make shared. but modeling good looking low-poly trees has so far eluded me. i'll still try.

tire walls, fences, and tree walls will need some kind of procedural bits i think. something like being able to draw lines in blender and have the game assemble them at run time.

== some other questions
should i be doing this? does everyone still think shared objects are a good idea? if yes, what should i try doing next?

***joevenzon*** · 02-11-2011, 11:41 AM,

Nice work, looks good.

zimluura Wrote:should i be doing this? does everyone still think shared objects are a good idea? if yes, what should i try doing next?

I think they're a good idea. Ideally, it'd make it easy to build a new track: just model the road and terrain then populate it with objects. Also, if you were to go back and redo one of the trucks or something, it would change in all the places it's used at once, which would be neat.

I'm hoping NaN pipes up about his idea for a new track format.

One of the things that the new GL3 renderer supports is a better material system, where you can set named textures and variables on an object and they get passed through to the shader.

charlieg · 02-12-2011, 09:01 PM,

NaN · 02-14-2011, 02:02 PM,

Sorry, haven't looked into it recently. But here are some scripts I wrote some time ago.

1) Look for mesh duplicates, extract relative position, orientation, replace with original mesh. Works great for some test cases not so great for VDrift tracks. The problem is to find a good comparison key.
http://pastebin.com/wHtdC9XM

2) Separate duplicate selection to allow user to verify duplicate candidates.
http://pastebin.com/6skVKPJD

3) Relative transform calculation and duplicate removal for the selected objects.
http://pastebin.com/pbRA3yHk

What is missing is a modified jpk exporter to write out object transform, texture, mesh into a text file.

zimluura · 02-14-2011, 04:46 PM,

chalieg: those look pretty good. squiggly-tree-in-fall has some artists notes on the page. been working on a fir tree of similar design.

nan: i had thought i'd just do the manual labor deal on rouen once the game engine support is in. you're much better at automating things than i am (i've been meaning to try the steering wheel but i haven't got a new enough to compile glew installed yet).

haven't any productive time with the track editor. was thinking populating a track with shared objects might one day be done in the game engine itself. free-cam mode, then fly around and click where to place things. as for linking textures to meshes i'm not sure. perhaps if each object has a text file (like the cars). then each object could be expanded (seasonal textures for trees, masses for road cones or anything with collision) arbitrarily as the shared object system permeates.

NaN · 02-15-2011, 05:51 AM,

Let's keep it stupid simple(commented out properties are optional):

1) separate body from object:

Code:
[body.001]

model = foo.joe

texture = bar.png

#size = 1, 1, 1

#mipmap = true

#blend = false

#clamp = false

#lighting = true

#emitter = false

#shadow = false

#skybox = false

#surface = 0

#mass = 0

[object.002]

body = 001

#position = 0, 0, 0

#rotation = 0, 0, 0

2) object instances override properties, more flexible:

Code:
[001]

model = foo.joe

texture = bar.png

#prototype = default

#position = 0, 0, 0

#rotation = 0, 0, 0

#size = 1, 1, 1

#mipmap = true

#blend = false

#clamp = false

#lighting = true

#emitter = false

#shadow = false

#skybox = false

#surface = 0

#mass = 0

[002]

prototype = 001

position = 10, 50, 0

zimluura · 02-15-2011, 02:42 PM,

#collision = foo-collision.joe

i had thought more like this:
data/track_objects/street_utility/roadcone for everything but position, rotation, and scale

then when they appear under data/tracks/rouen/objects.txt
we'll most likely say

[track_objects/street_utility/roadcone]
position = 10.32, 22.32, 3.4

[track_objects/street_utility/roadcone]
position = 22.12, 4.32, 2.12

# this one has other possible parameters
[track_objects/street_utility/roadcone]
position = 22.12, 4.32, placeAtGround
rotion = 0,0,random

the main advantage is that you don't redefine the road cone's parameters in each track that uses it. that way, a fix to the road cone's mass will propagate to all tracks immediately. i think, in the shared objects folder there should be some categorization, because, like rims, it's a directory that should eventually have tons of files.

do you see any red-flags/land-mines in that approach?

NaN · 02-15-2011, 03:43 PM,

It's option one with external config files. What about:

Folder naming:
cars
carparts
tracks
trackparts

data/trackparts/street_utility/roadcone

Code:
model = foo.joe

texture = bar.png

#size = 1, 1, 1

#mipmap = true

#blend = false

#clamp = false

#lighting = true

#emitter = false

#shadow = false

#skybox = false

#surface = 0

#mass = 0

data/tracks/rouen/objects.txt

Code:
[roadcone_a]

object = street_utility/roadcone

position = 10.32, 22.32, 3.4

rotation = 10, 0, 0

[roadcone_b]

object = street_utility/roadcone

position = 22.12, 4.32, 2.12

Just need to figure out how to differentiate between internal and external definitions. Spamming the file with includes would be really ugly. I've been thinking about getting rid of the include anyway.

Quote:position = 22.12, 4.32, placeAtGround
rotation = 0,0,random

I think this should be done in the track editor to keep the loading logic simple. Btw the random value would be different each time you load the track. Or is it intended?

zimluura · 02-15-2011, 05:44 PM,

cars, carparts, tracks, trackparts sounds really good. further thought: could probably make each reference more concise by removing the data/trackparts, because everything in that list would be from that directory, so just: [street_utility/road_cone]

i'd thought allot about the randomness. ideally i could see having one that is randomized with every track load. the road cone's z rotation, for instance (then again i don't know maybe the track staff drop them with only a +/-5 degree variation in their rotation)

but then there's another possible situation where we'd be better off having a seeded random number that is consistent between level loads:
for the nurburgring we'd want to use shared indigenous tree meshes. but we'd start with maybe only 3 different pine tree meshes. so for every pine tree we'd want to randomly select a pine tree from those available, but also have that selection hold for any other time we load that track. and only if the amount of selectable trees increases would the results be different. something like srand(0), then each semi-random instance is rand() % number_of_trees_to_choose_from. so if we add more later they all propagate automatically through the rest of the ring with an even distribution. tree mesh z-rotaion would want to be that way as well. x and y rotation on trees mostly would want very slight variations. and maybe only by the artist's hand.

that was sorta wordy, did i write out that thought well?

***joevenzon*** · 02-17-2011, 11:37 AM,

Just my two cents, I think having random values on each track load is a bad idea, because some random results won't look good, and you want the track artist to be able to make sure what the users are going to see looks good.

zimluura · 02-17-2011, 07:01 PM,

joevenzon Wrote:...some random results won't look good...

if you do it for the z rotation on the road cones it won't look as organized as it might otherwise. but may look more realistic.

joevenzon Wrote:...you want the track artist to be able to make sure what the users are going to see looks good.

well, it would be up to the track artist to use the random parameters if he sees fit.

i'm not trying to shout you down. i _don't_ think being able to have random parameters is of critical importance. the random-on-load road cone z-rotation would make very little difference.

but a more useful one would be for the trees (objects which there are tons of). and they shouldn't be different each track load. but every time the data changes.

if i were to attempt to switch out all the trees in the nurburgring for shared tree meshes, it would be nice to do it once, and not again if there are 7 more tree meshes added.

something like
[trees/indigenous/semiRandom]
position = 678.34, 121.342, 549.321
rotation = 0, 0, semiRandom
scale = 0.8 - 1.2 semiRandom

[street_utility/roadcone]
position = 3.21, 8.76, 18.94
rotation = 0, 0, randomOnLoad

everything with semiRandom would be randed from a constant seed. so it would be in the same position on each load, unless the data changes.

but again, it's not something of serious importance in the short term.

***joevenzon*** · 02-17-2011, 11:05 PM,

I think we're in agreement. My point was just that having it be random for each load is probably not a good idea.

Having a track editor feature to randomize is a good idea.

NaN · 02-22-2011, 05:54 PM,

Initial shared track objects implementation is in trunk although not feature complete yet.

Current issues:
Translated/rotated objects are not properly registered as collidable. Need to pass the transform to collision world.

Missing features:
Implement support for a shared track objects directory.

Look for the ambulance on rouen. Smile

Current wip parameters(commented out ones are optional):

Code:
[body.foo]

texture = diffuse.png

model = body.joe

#clampuv = 0

#mipmap = true

#skybox = false

#nolighting = false

#transparent = 0

#isashadow = false

#collideable = false

#surface = 0

#mass = 0 # mass, to be implemented

#size = 1, 1, 1 # axis aligned bounding box, to be implemented

[node.bla]

body = foo

#position = 0, 0, 0

#rotation = 0, 0, 0

NaN · 02-22-2011, 06:04 PM,

Here is a hacked conversion script. Warning only tested with rouen.

Code:
import os

def locate(pattern, root=os.getcwd()):

    for path, dirs, files in os.walk(root):

        for filename in [os.path.abspath(os.path.join(path, filename)) for filename in files if filename.endswith(pattern)]:

            yield filename

root = 'D:/vdrift/data/tracks/rouen/objects'

pattern = 'list.txt'

objects = []

for filename in locate(pattern, root):

    file = open(filename, 'r')

    object = []

    line = file.readline()

    while line != '':

        line = line.strip()

        if len(line) > 0 and not line.startswith('#'):

            if line.endswith('.joe'):

                objects.append(object[:])

                object = []

            object.append(line)

        line = file.readline()

    objects.append(object[:])

    file.close()

filename = filename.rsplit('/', 1)[0].rsplit('\\', 1)[0]

file = open(filename+'objects.txt', 'w')

count = 0

for ob in objects:

    if len(ob) == 17:

        file.write('[body.' + str(count) + ']\n')

        file.write('model = ' + ob[0] + '\n')

        file.write('texture = ' + ob[1] + '\n')

        if ob[15] != '0': file.write('clampuv = ' + ob[15] + '\n')

        if ob[5] != '0': file.write('transparent = ' + ob[5] + '\n')

        if ob[2] != '1': file.write('mipmap = false\n')

        if ob[14] != '0': file.write('isashadow = true\n')

        if ob[3] != '0': file.write('nolighting = true\n')

        if ob[4] != '0': file.write('skybox = true\n')

        if ob[8] != '1' and ob[9] != '1': file.write('collidable = false\n')

        if ob[16] != '0': file.write('surface = ' + ob[16] + '\n')

        file.write('\n')

        count = count + 1

count = 0

for ob in objects:

    if len(ob) == 17:

        file.write('[node.' + str(count) + ']\n')

        file.write('body = ' + str(count) + '\n')

        file.write('\n')

        count = count + 1

file.close()

alex25 · 02-22-2011, 06:42 PM,

NaN Wrote:Initial shared track objects implementation is in trunk although not feature complete yet.

you left out the shadows that i just added back in this weekend. can you update objects.txt from the latest list.txt? thanks.

--alex--

Login
Username:
Password:	Lost Password?
	Remember me