Game: Track implementation

[Michael Hartlef]

This topic is about how to implement the race tracks into the game. Please post your ideas and oppinions here.

[Petr Schreiber]

Hi Mike,

think of the following like of brainstorming rather than something mature.

- thought #1
Track completely done in some modeler, imported just as model = pure madness.
Why? - Some things will be just decorations, but colision detection routine could not autodetect it.

- thought #2
Per triangle collision would probably eat too much processing power ( unless written in Oxygen ).
That leads me to the idea of tunnel: ideal line throught the center of track, surrounded by tunnel - maximum deviation radius.

- thought #3
It would be nice to have alternative paths in the math, so the track editor should contain some AI " choose track suggestion" factor too

- thought #4
What is the track :)? Should we pick the idea of tunnel, or even more open space, such as wasteland ( ruins of city )


Petr

[Michael Hartlef]

Hey, thanks for the suggestions. But don't ask me alone. The others are welcome to discuss this too. Some thoughts of yours are very similar to mine.

#1 I would rather see a trackeditor where you can build the track with building blocks and place them visualy. This editor could save them. The modeling section would provide the block models and then everyone could build a track. If you want I can try to come up with some ideas (3d) for these building blocks.

#2 I don't like the tunnel idea. It's visually to similar. I would rather consider using insible geometry, or collision areas. These could be created inside a track editor. We would only need collision to the bottom and the sides. Top is not important.

#3 Yes, definately, you also need them when an AI ship wants to overtake.

#4 I would stay with track designs, but not with tunnel only.

The track editor would be used to build the track, set the waypoints for the AI, set the rest of the environment, define the collision areas, etc.

[Petr Schreiber]

Hi Mike,

now I get it. I downloaded demo of WipeOut 2097, so I have the idea of what track is - like a road with mantinels. That sounds ok to me.


Petr

[Simone]

Hi guys,

If I understood correctly the ideas is to create a map editor for the track where we design the track and assign into it a waypoints for AI.
I like it, it's same ideas that i have for Arkanoid Game where the map editor create a file with the character of map.

the track in open space sounds better of a tunnel for me.

Ciao,
Simone

[Petr Schreiber]

Hi Simone,

my idea of open space has one problem - it is quite tough to design. If we have track ( like highway ), it can be quite simple, and artists can decorate it in Potiemkin way ( no need to design where player will never hover ).

It would be quite cool to go hi-speed in ruins in desert, but I cannot predict how much work would it mean for our artist friends. Also - too big space means higher requirements for design. If you have smaller space ( just left / right side of track m ), then you can put there more detail to remember. I am curious what other think.


Petr

[Michael Hartlef]

for me it would not be a problem with open space. Petr, imagine running races Only in tunnels. How boring is that? An open track can have buildings, bridges, a sky, whatever. It looks more interesting. I think the track elements are not the problem. I think texturing will be the tricky part. but hey, I'm not alone here. So I will go by what the majority wants.

[Petr Schreiber]

Ok,

I would love to have Open Space too, but I was thinking of how much time we have to finish this ( no so difficult from programming point of view ).
Let the modeler guys say what they think they can manage.


Petr

[kryton9]

Since most games start out with an easy level and get more complex, I think this would lend itself to track and game play development.
We could start out with a training course to get the player used to controlling their vehicles.

1. Simple oval track, to test speed vrs better handling.
How to get powerups and perhaps what they do

2. Put in jumps, loops more advanced track feature training.

3. The First Real Racing Level where the driver would face opponents and be out of training mode.

[Michael Hartlef]

My intention of this topic was how a track will be implemented. Means technically. In one peace. Or in elements (block) and so we need a track editor where oyu can put these elements into a full track. Does anyone of you know the game "trackmania" ? If not, download the demo or the free nations game and play with the track editor. I would like to see such a thing in our game. A different thing could be to have an editor where oyu can DRAW the track and the track elements would be created out of this.

[Michael Hartlef]

Ok, after I spend the day playing with my son WarCraft 3 I think I will try to come up with some text track blocks and will try to create a simple track builder. I wanna see how I cna get this done so maybe then we can decide more easier.

[Petr Schreiber]

Hi Mike,

I took tiles approach for my bachelors thesis prototypes, you can see result in attached image.
Problem on my side was fixed tile size - too evident structure :)

But if we could make some more varied system for blocks it could look good.

Petr

[Michael Clease]

Why are the block sizes fixed?

[Petr Schreiber]

Because I wanted to be able to store it similar way as in Labyrinth - just matrix of ASCII characters, each meaning tile.
The requirement was to keep it simple. This is not good for exteriors as you can see.

Game could use variable tile size.


Petr

P.S. I apologize, but I must DIM myself AT bed now, will spend ... nice ... whole day in school tomorrow, better to sleep now than in the class :)

[Michael Hartlef]

Hi Mike,

I took tiles approach for my bachelors thesis prototypes, you can see result in attached image.
Problem on my side was fixed tile size - too evident structure :)

But if we could make some more varied system for blocks it could look good.

Petr


Nice one, here is my try. These are quick builds so don't judge the shape. I just wanna visualize what I ment with the track blocks.

[Petr Schreiber]

Hi Mike,

this looks very good!
I was thinking that having tiled geometry could help us with easier collision detection too.


Petr

[Michael Hartlef]

Hi Mike,

this looks very good!
I was thinking that having tiled geometry could help us with easier collision detection too.


Petr


Should I put more effort into this and think about this further?

Btw. here is a picture of a trackmania track without textures. The editor works the same like I envision it for our game.

http://hosting1.media-e.com/product-images/screenshots_big/ecd008299m_2.jpg

[Simone]

:o

Hi all,
Sorry for my absence yesterday.

Nice track, would be very nice to be able to add at the game. subdivide the track into a blocks it's great idea.

maybe we can assign to each blocks some properties of that part of track.
for Example: if it is a curve we can assign at the properties of a block the angle and the forward of curve for simple manage of Hovercraft AI and collision.

what do you think about this ?

Ciao,
Simone

[Michael Hartlef]

I let Petr answer this but certain parameter, sure. I was thinking about that you could define collision areas inside the track editor. Something like that.

[Petr Schreiber]

Hi Simone, Mike,

that trackmania screen looks good!
So I am all for it. I just see there some potentionally problematic places for collision detection ( like when road bends and goes up at the same time ). The tiles Mike presented were more 2D in some sense, more easier to do.

I need to think about the collision for such a more advanced cases.


Petr

[Michael Hartlef]

I allready can smell some nice additions to TBGL and thinBasic because of this project. :) Funny, that is how it works with Blender at the moment. The biggest pushes were included when they made the movies.

[Petr Schreiber]

I will be happy to add new stuff to TBGL,

this project is big challenge, I like working on it.


Petr

[Michael Hartlef]

I forgot to mention that I started on an editor/builder as a concept. If you guys like the approach then we can use it. I'm surprised how easy it is to setup a UI for it.

[Petr Schreiber]

Perfect,

do you use TBGL canvas + UI module or your new GUI functions?


Petr

[Michael Hartlef]

TBGL Canvas and UI.

[Petr Schreiber]

Nice,

I am happy Eros designs UI the way he does, that allowed hooking of TBGL canvas easily without any trouble.

One thing I was thinking of - if you remember my AI demo, there were some waypoints. If the track editor could autodefine them for final map, it would be very useful feature saving lot of time.

Which approach do you take for tiles - do you center them at 0,0,0 or other way?


Petr

[Michael Hartlef]

Which approach do you take for tiles - do you center them at 0,0,0 or other way?

The center of the base is at 0,0,0 modeled. The best for collision detection might be a raycast collision detection.

[kryton9]

Nice work Michael. The screenshots you and Petr put up helped me understand what you meant by tiles. Thanks.

[Petr Schreiber]

Hi Mike,

thanks for the information.
Raycast could work ok, as long as done just on current tile for example, that could mean quite low overhead.

I guess it is time for TBGL function to shoot ray against model :)


Thanks,
Petr

[Michael Hartlef]

Not sure if we have a DistantstoModel kind of command. I think we do or?

We could use it very nicely. It could help to detect the banking and slope of a track under the vessel. 4 rays from each corner of a vessel downwards. By the length of a ray you know if it goes up (front length shorter then back so you have to lift the nose. Left rays shorter than right, you have to tilt the vessel to the right side.

About the editor. I have now the rest of the week off. Playing babysitter for my son. But I have to enfing in the night so in about 2-3 days I will be able to show you somwthing. I hope! ;)

[Michael Hartlef]

I will post something about this raycast idea in the Hovercraft AI topic in a view sections.

[ISAWHIM]

Since the game is played with a gravitational guide... the track does not have to be limited to a set horizon. (Or even a full loop.)

You could make the whole game tracks without a solid form. Stackable like the old car-tracks for match-boxes, but with more curves.

You would only need to tell the program which angle the next section of track will deform to. (In essence, the track never moves, only the images slide under you. The track acts like rubber, bending to the next level of turns.)

The "Fill-objects", like side structures, braces, buildings, guard-rails, lights, bridges, and tunnels... Would simply move past you, around the curves of the bent track. Along a similar moving path, on the right or left, or just based off the horizon value.

That would also simplify mapping, and graphics. (The offset would continually slide on X or Y. Once aligned, it makes a perfect moving road.)

The actual track would have a wide "U" shape, so no real collision would be needed. If you go to far to the edge, you roll and flip-over, taking damage, and slowing down. (Also makes for a nice "Push" strategy. Heavier ships may be a little slower, but they can easily drive people into a banking roll.)

The long track would be sectioned, like a super-long millipede. Curves, banks, and depth could be modifications to the LEFT and RIGHT side, resulting in a hill, a drop, a curve, a twist... The space directly under your ship is always horizontal, in the middle. (Thus, that actual wide section never even changes, except for moving left/right, as you near the edges.)

The end of the track, the sections would be progressively more and more transparent, so they fade to the background. Though, you could permanently throw an overall ARC on the 3D, so it always ends below, and out of view. (With a majority of the track in front of you, being an immediate location that you will run across.) Creative "fog" or "clouds" could mask the distant track also...

I keep seeing a "Steam-punk" style... (Future, with recycled technology, half used correctly, and substituted with any junk that fits, to make it work.)

[Michael Hartlef]

Actually I have problems to visualize your idea and then how an editor for this could be easily made. Could you provide some mockup visuals?

[Michael Hartlef]

Also how would this be handling more open areas like in a desert for an example. And you said U-Type. I would like to see different track shapes, not only U-type. My fast designs are U-Types, but that was just to help visualize the tile idea.

[ISAWHIM]

I will make a few samples... (With what I have. I don't have much for 3D at the moment.)

Think of a roller-coaster track... (The rails being the side-walls, and the "Floor" is just the angle between the left and right rail. Except the width between the rails can be changed, making the "Floor" wider.)

Since the "Virtual" play-field is actually 2D, there is less collision to detect. Only player to player. (That is why I suggested having a flip-over side wall... We could land like cats... and continue racing, at a loss. Or, you could make it so we never flip, and just continue to slow-down as others attempt to push us up the wall, like a loss of propulsion footing.)

The actual "Drawn" view, would be 3D, bending and twisting. By deforming the track based on time, position, and the track attributes at that distance.

Only the lasers and bullets would look odd as they too, would travel the same "Distorted" field. (If we are going to have those...)

I was just not sure how large a field that thinBASIC could handle. Without culling, LOD, or with large maps... spinning 500,000 points around fast, requires a lot of processing. As opposed to altering the position of 10,000 points. Also, with limited texture ability... mapping large areas will be a daunting task.

The track editor for this setup, that I am talking about, could be like this...

Track-01
Length = 50
S01 = Curve, Incline, Bank, Width, Length, Height, Style, Accessory
S02 = ...
...
S50 = ...

Curve would be an offset from the prior track... +/- 0.1 to 5 deg (Left or Right) {Bend}
Incline would be an offset from the prior track... +/- 1 to 10 deg (Up or Down) {Crest or Trough}
Bank would be an offset from the prior track... +/- 1 to 10 deg (Left or Right) {Twisting}
Width would be the width of the mid-section, between the last and the next track
Length would be the length of the mid-section, ...
Height would be the height of the side-walls of the mid-section...
Style would be the image-set for this length of track
Accessory would be the 2D or 3D fill-in, like an overpass, light, center-obstacle... etc...

[ISAWHIM]

If time becomes an issue...

I can see a completely open track... No borders, only markers indicating the "Track"...

Perhaps even some creative visual blocking structures. Making the game play more of a... "Make it to the end alive." or "Live the longest", as opposed to "Stay in the lines while coloring".

Subtle and generic land structures could be loaded on the fly, and slowly exaggerated to full form as they come into view. (Sort of the revere of SPORE, where the land masses grow as you get farther away.)

With a generic center-line, that could help the AI. Horrible AI players could be farther from center, and all over the road, while the better AI would be more on track, and using the correct speeds. (Not overshooting turns and less drifting.)

[Michael Hartlef]

Jason, thanks for your detailed desciption. For some reason, and your 2D comment, it sounds a like like old old racing games where made. I have a big problem to envision how to add a nice variaty of the track to it. Flat elements, Tunnels, loops, whatever. I think if I understood you correctly, your track is defined via parameters and not prebuild geometry, right? If yes, then it sounds pretty simple, visually. To the others, maybe you guys understand it better and can explain it to me in a different way.


If time becomes an issue...

That won't be. I deny to think about this ;D

[ISAWHIM]

Don't mistake what I was saying about the 2D aspect... All race games are mostly 2D in the core. (They use 3D elements in the new games, but they have hard-core programming engines for physics.)

I am NOT saying like pole-position... Hehe... I am saying... not X, Y, Z, like Grand-turismo. More like running through a tube.

With hovercrafts, you are always a designated height off the ground. Thus, even on a 3D track, unless there is a jump, you are essentially on the same horizon... you are just more left, right, forward or back on the track, and from the other players. (It is represented visually in 3D, but not in the program core. Even using a simple "Level" to represent height, is the most common airborne trick to reduce dimensional thinking... so players can run under one another, and flip over one another on a collision. That is why the games need a track. A center-line is defined, and the AI stays along the center-line, but veers into turns while avoiding or attempting to push players around.)

Irrelevant of the 3D view... all players are simply on a path-timeline, somewhere on the track.

I am going to toss-out the "Keep the track still" idea... but that is only because I have come up with what I think is a better solution. (To help you visualize it better.)

The concept is still the same... the track is a physical track that can be drawn at any location. However, it still does not use a "object file" to hold the plotted points and objects. The track would use the same sample-traits, that I wrote above, but would be dynamically "Generated" as it loads.

You only have to define the profile of the generic track, and based on the settings, it generates the track into an array. Since each object of the track is built from the prior tracks points, in the profile, all surfaces can be dynamically loaded.

Like the bones in a snake... The "Center-line", is the spine, while the ribs form the track structure. The actual location is irrelevant, since only your position on the center-line and distance left/right of the center-line are the only concern.

You can get an instant LOD for the track, by loading only what is needed, and does not slow down the game. If (X) is your position on a 10,000 segment track... and you have a LOD of 2,000 segments... lets assume you want to "Represent in 3D", (X - 40), to show the track you just passed and (X + 2,000) for the LOD of the track ahead...

Your Position (X)
For i = (X - 40) to (X + 2000)
Read the LUT of the track array...
Insert the values into the DRAW array for 3D display on the screen...
Send the DRAW array to DX/GL for rendering, based on the positions offset and camera and distortion...
Send the PLAYERS positions and angles of the 2D center-line location...
NEXT

You could use a PUSH to slide the new values of the array into the old array, for faster speed. You only have to look-up the next segment, and add it to the array... while the one that just dropped off, is out of view. (Remember, they share the same points on the connections, for the objects. Point X,Y,Z is used by the old object at the end of the track, and the new object loaded from the LUT. (Which is just the calculated profile, rotated to 3D space, based off the settings, which are relevant to the prior tracks settings.)

You could even make a "Random Track", using set limitations... Don't bank over 5 deg, don't incline over 12 deg, don't curve more than 7 deg, and all segments should be within 15 to 40 segments long. You end-up with a purely random track that is playable, and no 3D time spent making sure no surfaces have holes to slip through, no processing of track-collision (gravity and surface intersecting.)

You can programmatically handle the "Speed" on the turns, to balance it out to look natural. (When a center-line bends left and right, the inner curve would technically still have 1000 positions in 2D, as would the outer curve. That would make you appear to go faster on the outside, and slower on the inside of a turn. But calculating the distance from the center-line, on curves only... you can adjust SPD to balance... You should take longer to get across an outside curve, and less time to get across an inside curve.)

You have a similar issue with incline and drops... You would need to simulate SPD increase for any drops... like anti-gravity (Less weight as you coast down a hill. Gravitational acceleration/assistance.), while an incline would reduce your speed, as you are fighting ground friction, and a mini-g-force effect.

I am trying to remember the game which had a similar track setup... (Old arcade game, with a hover-ship, that traveled in a tube-style track, with flat spots also. It used markers for speed acceleration, and as bonus "Continue" marks. If your time ran out... that was the end of the game. Each mark you hit, delayed the timer a little... extending your time.)

Altering the track would only require adjustments to an individual segments values. Profile formulas could be extended to draw more, for greater LOD, setting a priority value for non-track items.

The non-track items would not be "calculated", those would be normal 3D objects. They would appear at a designated center-line offset, holding the same angles as the segment, but without the "Altered" or "Distorted" bends of the track deform. Eg, a light would angle to be horizontal to the segment, but the top of the light would not expand or shrink as the track bends or shrinks. Think of it as a toothpick attached to a snake-rib... as you bend the snake, the rib-points (track-wall points), get farther away. But the toothpick remains unaltered, except to follow the orientation of the attached rib.

LOL, I have been thinking about this all day and night... can you tell.

Just like in warcraft-3d... the game is still a 2D game. But it is represented in 3D.

Just like a planet game... The surface is flat... but it is wrapped into a sphere...

[Michael Hartlef]

Just like in warcraft-3d... the game is still a 2D game. But it is represented in 3D.

Funny that you are mentioning it but Jason, you are wrong. It is 3D, not only the graphic engine it uses. I just worked with the editor yesterday and boy is that a nice one.


With hovercrafts, you are always a designated height off the ground. Thus, even on a 3D track, unless there is a jump, you are essentially on the same horizon

There will be jumps, loops, tunnels, etc etc.


You could use a PUSH to slide the new values of the array into the old array, for faster speed.

Are you talking about thinBasic or a different programming language?


Send the DRAW array to DX/GL for rendering

We are using TBGL, that is using OpenGL under the hood.


All race games are mostly 2D in the core.

Can you name a few? Racing games are my favorites. Nascar from Papyrus, RFactor, GTR.


A center-line is defined, and the AI stays along the center-line, but veers into turns while avoiding or attempting to push players around.)

Just like PolePosition. 1983?

Ok, the track will be generated on the fly. I don't think that it will makeable with thinBasic, performance wise.

But Petr has to answer this, if this concept is something he would like to follow. Because all the collision detection and the autosteering would work different. If it would work at all. I actually can't see much advantage out of this but if you guys think it is better, then hey, less work for me.

[ISAWHIM]

I am sure that the game can handle the creation of 50 to 200 new surfaces a second... VB could handle full rotation and creation of 5,000 per second... and that was slow. ThinBasic is hundreds of times faster than that. Remember, only the new track positions ahead, are created on the fly. (But they can be pre-translated at the beginning of the game/level. But that is still dynamic creation. EG, no set "Constructed" path or objects.)

I call it an array PUSH... each language has a similar name... STACK, PUSH, ADD...
Dim MyArray(2)
MyArray() = "SUE", "JOE"
Add MyArray() = "BOB"
MyArray() = "BOB", "SUE"

In with the new, out with the old...

Here is a quick video I made... to give you a nasty idea of what the track portion may look like generated this way.
It is in two parts... Damn youtube limited the time to 10 min... it was 12 min long...

Video 1
YjQBQvGg9LM

Video 2
eiQTXAEhbRs

Odd, it wouldn't show the video using the youtube link button...

The concept of it being generated on the fly, is more for speed, and for in-line editing of the track. (Since you don't need a 3D model program.) You could just go into track edit mode, and adjust the attributes... Wider, taller, covered, bank, incline... Makes for easy debugging, and track creation also.

You could let them upload custom tracks... LOL... I am not a good sales-man.

Again, the greatest bonus I can think of, is the graphic overhead of huge BMP files used for mapping a track. If the track does not have good mapping, you have to fake it with higher-detail structures.

Has anyone setup a generic test-map (Object file)... For him to play with yet?

A simple figure 8 with an overpass is a good test of AI control. If it is going to have issues, it will be on the overpass area, where the tracks overlap, cross and change direction. Use an open field, and purposely add a random crash-block, directly in front of an AI racer... to simulate when it hits a wall. (It has to know how to back-out, and orient itself around the obstruction, which could just be a side-wall. Usually, they like to play the crash game, and keep running into the same thing. Eventually working the way out.)

Also, try a jump-ramp collision, and a jump-ramp fall... onto the wrong area of the track. (Like jumping over the 8 overpass, but landing on the track below. Cars don't always like to go around the long way, and tend to want to drive into the ramp from below, attempting to get to the center-line that they fell off of, from the jump.)

Most race games just make an AI path (Center-line), and create "oops" code, to fix those lovely moments. (Usually it pulls the car and drops it back into the race, somewhere behind, on the center-line.)

[Michael Hartlef]

Thanks Jason, exactly like I thought. What I don't like is that the profile of the track is all the same. Or would your algo take care of things like this variaty shown in the attached picture.


Has anyone setup a generic test-map (Object file)... For him to play with yet?

I wrote before that in around 2-3 days I have something to play with.


Again, the greatest bonus I can think of, is the graphic overhead of huge BMP files used for mapping a track. If the track does not have good mapping, you have to fake it with higher-detail structures.


See above, can your track algo tack care an create more detailed trackparts?

[ISAWHIM]

The track could have any number of additional objects to create the fullness. Light-posts, overhead sections, roof, contour styles... (As long as they connect with the common floor, and include the bank edges. Though, it would not be a complex task to create separate track-rules for an alternate profile.)

Going back to the snake analogy... with the ribs...

The ribs are the track contour, which would have certain adjustable attributes. Having another joining section, with a separate set of attributes would be more of a graphical task, than a thinking task for the AI. (Since it is still ultimately represented in XY cords for your positions, it is only the 3D representation that would demand more attention. Mostly to ensure that it "Looks" correct.)

A profile is a profile, and nothing more. It only determines how you see the track in 3D. It does not determine how you interact with it, as it would in 3D. EG, you could remove the track, and the vehicles would still follow the track rules from the XY translation. In 3D, without the 3D object, there is nothing to collide with. That is why you can "Jump through corners", and "Fall through seams"... In those micro-cracks, there is no object to collide with, and the ray-cast or physics codes fail, because they don't have thickness, and floating precision fails at micro-cracks in many formulas. (Well, in the fast formulas.)

I can throw some generic mapping on the track, and make some generic objects, to show how they would be oriented.

I will also try to show what a "Split" left/right track would look like. (Where the left half is flat, but raised above the right side, making a cliff or drop-off road. Though, that is just another style.)

For example, that profile had about 30 hard-coded points. That is all you have to remember in the program for that object. The extruded profile has 60 points, 120 triangles, and 120 edges. Each extrude adds...30 points (30 shared), 120 triangles, and 90 edges (30 shared).

a 5,000 segment track would have...
(60 p, 120 t, 120 e)
plus 4,999 x (30 p, 120 t, 90 e) = (149970 p, 599880 t, 449910 e)
total for 5,000 = (150,030 points) (600,000 triangles) (450,030 edges)

Leaves plenty of room to spare for other objects.

If each segment was only a foot long, that is about a mile of track. (Assume a ship is 6 feet long, and there are only 2 segments per ship-length. That would be about 3 miles of adequate track. Or one mile of high-detail track.)

(But remember, you would never see a full mile of track, possibly a 1/8 to 1/4 mile of track would be rendered at a time.)

At 60 MPH, a 3 mile track would take 3 minutes to complete, if you ran it perfect, and entered the race at 60 MPH at the start line. But, don't forget... this track is infinite... Instantly reversible, and instantly L/R swappable.

Though... if the track was built like I did the sample... we should call the game "Mag-runner", a play on the mag-rail trains. Since it does hover... but also sticks to the surface when flipped or driving on an upside down track.

Could also be worked into both stories, as the pollution-saver, or as the believable explanation as to why a mag-rail is used. (As opposed to a super high-tech "anti-gravity device"... But still high-tech enough to believe.

Hehe... No ramps... magnetic propulsion launch spots... and Sticky-mag rust spots... like mud...

[Michael Hartlef]

Ok Jason, let's see what Petr thinks about all this.

[Petr Schreiber]

Hi guys,

interesting ideas, thanks to all.

ISAWHIM, if I get it right, you are thinking of parametrized track, it would generate from defined points or using AI algo new track mesh on the fly?

I am with Mike on this - it could bore the eye a bit ( although from technology point of view it is cool thing ).

What I am scared of is your polycount budget - 600,000 triangles per scene? I we would design game for middle and high end cards, no problem. But for example my dev machine has GeForce6, which is able to render about 200,000 polygons using arrays at maximum, when script does not do anything else. Display lists can do the job better, but I was thinking of much lower track polygon budget.

From my experience, Intel cards hardly breath out even 40,000 polygons. So I would put polygon budget around this number.

From "mod community" point of view, I think it is more enteratining to put different looking tiles ( even self created ) for the track, rather than geometrically beautiful but uniform looking smooth road.

As Mike suggested, could you provide some sketch how would it look, maybe I understood it in wrong way?

Bright point of your idea is that the collision detection is really easy - just offsets from center line allowed to left-right and we are done.

Maybe combination of your "smooth snake road" and manually added assets could make the track more rich?

What others think about this?


Thanks,
Petr

[Michael Hartlef]

He provided 2 Youtube videos above.

[Petr Schreiber]

I am blind as a bat,

sorry and thanks. Now I see how it looks.
I should read the posts in less hurry :-[


Petr

[ErosOlmi]

Odd, it wouldn't show the video using the youtube link button...

ISAWHIM,

youtube tag works correctly. You need to insert just youtube video ID and not full url.
So just insert eiQTXAEhbRs in {youtube=425,350}{/youtube} tags (here I've used {} instead of [] in order to show the syntax)

{youtube=425,350}eiQTXAEhbRs{/youtube}

I've amended your post and you should see videos on-line in forum.

Ciao
Eros

[kryton9]

The tracks that Mike and isawhim did look great. Whenever I try to do a track in blender, I get frustrated, your guys stuff looks really awesome.

On the tile idea that Mike did. I had a thought in that the terrain tile looks to be a part of the track tile. Perhaps they could be split.

The terrain separate from the track and not even tiled really, just a separate model.

The track tiles could have the support structure beneath it that could extend out enough to reach the terrain below if necessary.

[ISAWHIM]

Thanks Eros...

The GeForce 6 can handle nearly 250,000,000 vertices. (About 83,333,333 triangles per second.)
http://www.nvidia.com/page/geforce6200_agp.html

The Intel 740 (1997) can handle nearly 3,300,000 vertices. (About 1,100,000 triangles per second.)
http://www.ee.technion.ac.il/courses/044800/manuals/ChipSet/Intel740GA.pdf

But... the numbers I gave for the track, was about the size in memory as an array. Unless you zoomed-out, you would never see or render all of them. (Also, not unless they were all visible. DX does face-culling automatically. Unseen triangles are not rendered. That is why a full map is possible, without a huge performance hit. But... DX has to translate all the points of the entire map, to determine what is visible, thus only a partial gain. This ARRAY holding the map, is separate of the data sent to DX. You only send a fragment of the data to DX to think about rendering. It will still perform the same visual culling, but on only 1/8 to 1/16 of the points in the full map array.)

That is how you handle LOD, prior to any dependency of external software or hardware. Think of it as low-level graphic acceleration.

That would be like sectioning off our solid maps using a series of VIS-WALLS... (The draw-back of a vis-wall, is that any map that you can move the camera in 360 deg... suffers a performance hit if you do a full 360... It has to reload the things you just passed, which were out of your visible view when you were just looking forward.)

I'll keep playing with the idea, just as a back-up... or a potential alternative... or as a project for a future event.

I just converted the code that draws lines with GDI, so I can start to play around with some 3D wire-frame structures, using only native thinbasic code. I figure that if I can get a little demo that displays some of the functions... you guys might be able to turn that into something more 3D. (I don't know how to create the points as an object, to send them to the 3D thing yet. But I can translate them as 3D, as a wire-frame in code, to know what it will look like.)

I am horrible with terminology... I am surprised you guys understood this much. I am use to people looking at me like I am speaking alien.

You can still simulate a good LOD with a solid track style... You just have to use sections, and play with in-game flow to determine what, and when, certain things should be removed, shown, or replaced with an object that has less detail.

For now, until I get more down... I am going to suggest that my idea be shelved... (I don't want it to get in the way of the development. Not until, unless it becomes a more viable alternative.)

But I still would like to have the "Mag-race", idea considered as part of the track implementation. (Like I said, it could help justify certain programming and control limitations, making them seem as if they are intended to be that way.)

Delayed input... delayed reaction... rampless jumping spots... non-contact friction... limited or reduced ability to turn... (Some things a hovercraft can explain, but some can not.)

Plus, it opens the door for the ability to have a track that is non-standard, based on gravity... You can make the track run right up a wall, around the outside of a cylinder (As opposed to inside it), invisible electric field track segments, magnetic missiles, ceiling driving (Which would reverse steering), anti-flip-over (Or cat flipping, as opposed to landing upside down, and resetting a player back onto the track)...

Adds more content to the existing story-line, and also gives this a non-clone feel... Adding that unique element.

[Michael Hartlef]

The Intel 740 (1997) can handle nearly 3,300,000 vertices. (About 1,100,000 triangles per second.)

Ok, again we are talking OpenGL here and not DirectX. Just to clarify. We are also talking quads, so devide these numbers by 4 not 3. My guess is also that we will need an internal framerate of around 200 fps for the rest of the game. Collision check, multiplayer work, AI. We are talking about an interpreted language here. thinBasic is fast, but can't be fast as an interpreted language.

The stats that these companies provide are raw numbers. No status changes no nothing. So if you take the thing I said into count, you will end up with 4125 quads with the INTEL and 312.500 with the GF6. Like I said, raw. No texture changes, no nothing. We have definately a limit here.


I am horrible with terminology... I am surprised you guys understood this much. I am use to people looking at me like I am speaking alien.

I agree on that. ;D


I just converted the code that draws lines with GDI, so I can start to play around with some 3D wire-frame structures, using only native thinbasic code. I figure that if I can get a little demo that displays some of the functions... you guys might be able to turn that into something more 3D. (I don't know how to create the points as an object, to send them to the 3D thing yet. But I can translate them as 3D, as a wire-frame in code, to know what it will look like.)

I'm very curious what you will come up with. And how editing a track will be. What do you think, when will you have something to show?

[ISAWHIM]

When will you have something to show.

I don't have my old VB files, which have all my old 3D formulas... So I can not estimate at any scale, when I will have something to show, in code. (I have to re-find my formulas on the net, convert them to thinbasic, and then hope that I get the same results.)

I am not sure how thinbasic handles a lot of math, so I can't use all of my old techniques. I need to develop new bad habits. ;D

The code I have now...
Using RND(0,800) to plot points for lines in a FOR loop... Results in 9.7 seconds to draw 1,000,000 lines. (I know that is not fast, but that is 0.97 seconds for 100,000 lines, or 0.10 seconds for 10,000 lines, which is fine for my purpose. 10,000 random lines fills 95% of the screen pure black. That is about 10 FPS for 10,000 lines.)

But the screen erases itself if any window passes in front of it? (I might have to use memory writing to a BMP screen buffer. Or just keep the window on top.)

Until I get code to work, I will just hand-make another example, the one promised before.

But I think the code would say more. (I think it is like a NURBS line, or a SPLINE. Again the terminology escapes me here. But the conversion code is nearly the same.)

[Petr Schreiber]

Hi ISAWHIM,



The GeForce 6 can handle nearly 250,000,000 vertices. (About 83,333,333 triangles per second.)
http://www.nvidia.com/page/geforce6200_agp.html

The Intel 740 (1997) can handle nearly 3,300,000 vertices. (About 1,100,000 triangles per second.)
http://www.ee.technion.ac.il/courses/044800/manuals/ChipSet/Intel740GA.pdf


if that would be true, why games from 1997 look so blocky? Vendors always take the most convenient case - like not texturing, no alpha test, mini resolution ... Those numbers are not real.

Without textures, I got OpenGL smooth in software mode on Pentium 150...
But add texturing, blending ... that makes your card busy :)

On my PCs I could not observe difference in speed between DirectX and OpenGL.

As Mike said, racing game needs hi FPS to get good impression of speed.



Using RND(0,800) to plot points for lines in a FOR loop... Results in 9.7 seconds to draw 1,000,000 lines. (I know that is not fast, but that is 0.97 seconds for 100,000 lines, or 0.10 seconds for 10,000 lines, which is fine for my purpose. 10,000 random lines fills 95% of the screen pure black. That is about 10 FPS for 10,000 lines.)


This is odd. You do not need to regenerate track each frame, you can go for display lists. If it is not problem for you, attach code here and I will make it a bit faster ( not because I am super good, I just think I know where do you make "mistake" ). OpenGL / Direct3D is not GDI, they are more elegant, with more possibilities to optimize ... and reduce flicker, brrr :)

Thing #2 - lines and points are the slowest entities in OpenGL, they keep constant width/size, they are processed differentely.

I don't know if you guys will agree with me, but I would choose to not use any LOD models. I think we will have other stuff to calculate ( AI, collisions, ... ) than if some object is far enough to make it ugly :)

I think backface culling will do the job, in case we are really low on speed.

ISAWHIM, thanks for your ideas again, looking forward to the code.

Here comes 10,000 lines at 40FPS on GeForce 6150 LE:


'
' 10000 lines
' Petr Schreiber, started on 10-02-2008
'

Uses "TBGL"

dim hWnd AS DWORD
dim FrameRate AS DOUBLE

' -- Create and show window
hWnd = TBGL_CreateWindowEx("Lot of lines - press ESC to quit", 640, 480, 32, %TBGL_WS_WINDOWED or %TBGL_WS_CLOSEBOX)
TBGL_ShowWindow

%Lines = 1
CreateRandomLines(%Lines)

TBGL_SetDrawDistance 1000
TBGL_UseVsync 0 ' -- Draw as fast as possible

' -- Resets status of all keys
TBGL_ResetKeyState()

DIM Sheep AS LONG

' -- Main loop
While TBGL_IsWindow(hWnd)

FrameRate = TBGL_GetFrameRate

incr Sheep
if sheep > 30 then
TBGL_SetWindowTitle(hWnd, "FPS: "+FORMAT$(FrameRate, "#.00"))
sheep = 0
END IF
' -- Clear image area
TBGL_ClearFrame

' -- Add rotating lines, cached in object "%Lines"
TBGL_Camera 200, 200, 200, 0, 0, 0
TBGL_Rotate GetTickCount/100, 0, 1, 0
TBGL_CallList %Lines

' -- Flush drawing
TBGL_DrawFrame

' -- ESCAPE key to exit application
If TBGL_GetWindowKeyState(hWnd, %VK_ESCAPE) Then Exit While

Wend

TBGL_DestroyWindow

FUNCTION CreateRandomLines( dlSlot as long )
LOCAL i as long
' -- New List = cache it for me, my precious driver :)
TBGL_NewList dlSlot
' -- Draws multiline
TBGL_BeginPoly %GL_LINE_STRIP
FOR i = 1 to 10000
TBGL_Color rnd(128,255), rnd(0,128), 0 ' -- Define color
TBGL_Vertex rnd(-100,100), rnd(-100,100), rnd(-100,100) ' -- Define point
NEXT
TBGL_EndPoly
Tbgl_EndList
END FUNCTION


Petr

[Michael Hartlef]

Petr, his algo is based on calculating the geometry for each frame, build it on the fly, texture it and stuff like that. Displaylist are then a nono, or? I doubt it will work with thinBasic but maybe Jason can prove me wrong here.

I'm surprised how fast I got a basic trackeditor done in thinBasic. You can place tiles, erase them, Save/load.

[ISAWHIM]

Hmmm... I suppose I should draw the graphs and charts of flow...

Hehe...
Short version...

1) Read data about track attributes from file, into memory.
2) Pluck section 1 attributes.
3) - Calculate point locations, set into P_array(1) (This is a profile slice)
4) Pluck section 2 attributes.
5) - Calculate point locations, set into P_array(2) (This is a profile slice)
6) - Calculate joining surfaces, 1 - 2, based on 1 attributes. (This is the actual mapped object section 1)
{O_array(1) = P_array(1) + P_array(2), built with surfaces mapped and cross-connected as triangles.}
7) Pluck section 3 attributes.
8) - Calculate point locations, set into array(3) (This is a profile slice)
9) - Calculate joining surfaces, 2 - 3, based on 2 attributes. (This is the actual mapped object section 2)
... Continue until end...

You end up with an array full of unaligned single objects. That is the full map.

Now, those have to be translated, since they are just default orientation, as if each directly under you. (Origin objects)

The second array could hold the XYZ offset of each sections (0,0,0) point, which is relative to the handle of the previous section. (The pivot point of the center-line is 0,0,0. The end of the center-line is the handle.) The array also holds the PYR (Pitch, Yaw, Roll). {This is if using ORIGIN an sending (XYZ, PYR) are your method of display.}

However, if you need physical points... The original array would be directly modified with the orientation, based of the attributes. (As opposed to storing the (XYZ, PYR), those values would be used to change the values of the map points. The surfaces would not change, they are still connected the same way.)

Now the map is in memory, and could be loaded into view... But you don't want to see the whole map, just a portion.

The "View" array... is filled with the section you want to see. (Could actually be a low-level machine memory copy, since the array should be the same. Only if there needs to be a "Special" format for sending to the render-engine, would you formulate INTO that new array format, using the "Altered objects" in the whole map array.)

Now the game starts... Your whole map is in the big array... your VIEW is in the small array... (Though you might not see the whole view, this is just what you choose to keep in memory, so the players don't see what is going on. They can see the whole view, if it is designed to see that far ahead. But the FOG or FADE should mask before that distance.) Technically, you could let the game decide. Run through the track, and do a manual VIS checking... (See how far you can see, and create a load-map based on the position on the track. You could manually tell it to load X sections at that position. If you are in a tube, and you can only see 10 sections ahead... only load 12 or 20 or 30... etc...)

You pass ten sections, ten are dropped off from rendering (behind you), and ten new objects are added into the array. Since the objects have their own XYZ locations, it will not matter where they are in the array, they will render in the correct location. (You do have to track which ones are next to be removed. That would be a rolling value.)

So... in essence, while playing the game... it is dynamic, but the map is only being constructed as you approach new sections. I used a "View" array... because I am not sure if GL interacts with the array memory to display content, or if it uses its own set of arrays for that stuff. (I am use to shared memory hDC, where rendering objects alter your data, and you can get values from that data, as opposed to talking to the module.)

You might not even need the second array... (Again, I am not sure how you communicate with the GL, or what formats you are using, or if you are just giving it raw details about the objects.)

Looks like you could use your editor to create dynamic maps also... (Faster than my idea.)

If it stays modular like that... You could use the same LOD by removing sections that are the furthest away... (On the complete opposite side of the track. You could ensure that no visual loss comes through, by using a large centerpiece, like the city. Keeping the skybox on the outside, as the glass bubble.)

[ISAWHIM]

Oh, for the record... When I say LOD (Level of detail)
I am not talking about poly-face reduction (Turning circles into stop-signs)
I am talking about whole-scene level of detail (Removing physical objects that are unseen or insignificant to near-view.)

The game should know that if there is less free time after releasing a frame for display, that things are getting bogged-down, and some far-level objects should be removed. Just as if it has lots of free time after releasing a frame for display, that it can reach farther into the bag of detail, and load more distant objects.

No sense attempting to draw 100 FPS if you can only see 60 FPS. (60 hz = 60 full screen redraws per second, or 60 Frames per second. The eye cant see faster than that, and below 30 it gets too jumpy. Faster than 60 and the screen flickers if you don't have higher refresh rates. That is why many people don't see any performance gains with better cards. The CPU does, because it is thinking less, unless the gain is visual, which is usually the case. But I think this will be like top-down, and fall into the 30-50 fps range, with the full maps sent to GL for processing.)

[Michael Hartlef]

No sense attempting to draw 100 FPS if you can only see 60 FPS.

Visually of course not but without VSYNC on we have to attempt even 200 FPS just for the 3D part. Then comes AI calculation, physics, network, input, collision, particles, sound, etc etc.

[Michael Hartlef]

And how do you envision the track editing?

[Michael Hartlef]

another question as you might also noticed that I'm not really convinced. What is the advantage of this against the method we are approaching. I simply can't see it. The only thing I see it is different. Performance wise I think it will be more stress on the system but there I could be wrong.

[Simone]

Hi all,

as I understand, we are choosing which method to use to create the track.

One is to create a Track model based on tiles.

But I am a little confused about method suggested by ISAWHIM
He plans to create a configuration file that the script has to interprets step by step ?

Ciao,
Simone

[Petr Schreiber]

Hi ISAWHIM,

I am not sure, maybe you are used from classic GDI programming that rendering redundant geometry comes at too high price...

But on 3D card, from my experience, the less difference between two frames regarding the load, the better performance I get.

Although ThinBasic is fast, we should keep in mind it is interpreted - therefore some realtime mesh generation and deallocation during race seems to be not very good approach. I understand your idea, but I guess this kind of optimization could result in worse performance in the end, because it took more time to decide what and how to draw, than in case of simple geometry rendering without much thinking.

As Mike said - nono for display lists. Virtual model slots could be used ( they are quite fast in last TBGL, sometimes even as fast as display lists ), but still it would need some data transfers.

When we would render whole New York in realtime, that is different thing - but single track? I think it will not be so heavy on polycount.

I read a lot of theory on such a optimizations, but usually the speed gain is not so great and the code is lot more complicated. Other thing is the framerate gets less balanced, which means less precise integration of position of vehicles for example.

I am afraid the advantage of easier collision detection would be degraded by this realtime "modeling".

I can see Mike can put track together in very short time, so currently I would vote for the tile approach.


Petr

[ISAWHIM]

I vote for the tile approach also... Hehe...

For that same reason... quickness of design... (And available code.)

I am going to force a full demand of my idea being shelved... (Not a demand on your half, on mine... or I will keep rambling.)

[Michael Hartlef]

Oh well :-\ I would have loved to see this in action, if it would result in a nice detailed track with a nice variaty.

[ISAWHIM]

LOL... I would much rather see a completed game submitted, than a half complete concept. (I have not stopped thinking about it... just stopped trying to explain it badly.)

I have access to the GL help files now... so I can study what you guys already know. (My knowledge is all based on direct creation, since I never had an editor, beside the ones for Quake and Unreal, and Need for speed. I don't even know how to use CAD or blender or any other complex editor. I have lived off script-created geometry and SketchUp for years.)

Yours will do the same... only faster... (But it still needs to create a few outputs. Map_Object, Map_Attributes, AI_Path, and Fill_Objects.)

I will enjoy making suggestions on that, as that develops. (It will help me learn how or if it is possible to implement my old idea.)

Might be safe to lock this topic, since no other suggestions have been made. Create an area for it in the CODE section, so we can throw some ideas at you.

[Michael Hartlef]

I will enjoy making suggestions on that, as that develops. (It will help me learn how or if it is possible to implement my old idea.)


And I enjoy them comming, even it they make my head spin. What idea is that? Care to share?

[ISAWHIM]

Old idea = The one about the track building off itself.

I am playing with some formula attributes, trying to give the crafts some physics. Once we have a collision set of code to play with, we should be able to drop them inside your map for testing.

[ISAWHIM]

Ok, sort-of ignore this post, I am just writing this to get it out of my head... but place it in an appropriate area.

Here we go again... Hehe...

If the "Points" of the track actually defined the track itself, the AI and us, can be confined to that loop. No matter what the shape.

If some attributes of the "Points", were... (LOL, this will sound similar to my above posts.)
- Width (Defines the connecting outer limits "Joints".)
- Height (Defines the position off the "Base".)
- Bank (Defines that outer edge/s sweep-up.)
- Covered (Forces a roof, which is required for any "Overpass".)
- Mapped (Uses a M15 file for construction. Otherwise it is a simple walled structure.)
- ID_Type (Normally 0 "null", but specific "types", would be used for programming/editing/play.)
- - (0) = Generic (No special attributes.)
- - (1) = Start/Finish (Acts as a lap-counter and performs the initial launch/ending.)
- - (2) = Wide Bend (Bank is more subtle, larger flat, limited length min/max.)
- - (3) = Tight Bend (Bank is high, inner is folded and locked "post", limited length min/max.)
- - (4) = Crowd bleachers (Fenced bleachers, limited length min/max.)
- - (5) = Overpass (This would be the under side, that allows a (0) track to cross over it.)
- - (6) = Tunnel wall (Provides a cement/roof to intersect a building or mountain, to pass through.)
- - (7) = Tunnel ground (Similar to wall version, but with ground slice, like a subway.)
- - (8 - 255) = User defined. Not available for now...

Separate of the "ID_Type", there would be a style... (Profile or Structured.) So a "Tight bend", would simply tell you the shape, while the style would determine what that shape is constructed of. A "generic" style would be default also. Just a track, and walls. While a custom profile or a fixed structure M15, would replace the generic shape, or add to it. The type would be the same for both. EG, limits, functions, effects...

The ID_Type would be used by the program, similar to a script. It determines what reactions, limitations, sounds, objects, etc... will suit the length of track.

From point to point, is a "Length". However, with the above options, a point can have points in its length. Since the points have a width, and in a "Track", paths with walls don't cross one another, you can connect the round points with edges to form the track visually and for the AI at the same time, using the same points, or overlap them to stop walls from drawing.

Further "Map" traits could also respond to the points.

If there were mountain terrain created from a BMP for height, the BMP could be modified with the track points level and width values, to raise or lower the terrain to form around the track.

If there were generic objects, like trees and bushes, and buildings... they could pull-up to the edge of the map, or near it, while avoiding overlapping. (As opposed to placing trees or making a special "Tree section track". Just define a box as woods, or city section. The limitations would be in the file for the map, not the track.)

Since this is specifically a "hovercraft" track, it would be safe to assume that the entire track has walls of some sort, but the walls don't have to be on all inside edges. EG, two flat generic tracks overlap like an 8 but the joint in the center is not a CROSS, the two tracks just touch enough, and no wall is drawn. There is a "Chance" that if you overshoot your turn, you will fly into head-on racers that were behind you! That is always fun. That can be a good thing for the track, to give it a more open feel. The surrounding objects would fill-in, up to the edges of the track... This would be cool if it sliced into a mountain terrain, looking like joining valleys around two towering plateaus.

A sample of a custom section of track, would include the "limitations" for placement, size, etc... as well as, containing an M15, or multiple M15's. Objects inside could be collision objects, or scenery, or scripted. Scripted objects would be simple pre-made scripts that exist in the game itself. A value would indicate the CASE, and hold any parameters.

Sample scripts would be...
- (0) FxSparks(X,Y,Z,Size,Type)
- (1) FxLaunch(X,Y,Z,Width,Length,XYAngle,Power)
- (2) FxSound(Name,Loop,VolIN,VolOUT)
- (3) FxLeaves(X,Y,Z,Size,Type)
- (4) FxSand(X,Y,Z,Size,Type)

etc... (Particle effects, shared functions, shared attributes.)

So you could make a desert track, have jumps, put sand on sections that blows around as you pass over that area, add oil-pump sound effects, and use your own geometry, or others geometry...

Ok, I am done... I am going to finish learning TBGL now... (Yea, like I am almost done. LOL.)

You might be able to use some of that for the track editor... (I have not played with it yet, but I am guessing it only outputs the map, in this early stage.)

[Michael Hartlef]

Boy, I think we can better discuss 3rd world child suffering with all these dicussions. ::)

To Petr and anyone else who think is able to provide usefull code to the game. Please come up with a describtion how you want the track implemented so we can start putting a sample track together, with or without an editor.
And before someone comes out with a major science paper over 30 or more pages. Remember, we have to deliver something in january and it would be great to have some dummy artwork by the end of this month.