Racing Game

[Neoteric]

After having done a little research on Java3D I decided there wasn't anything like enough support or examples for it, so I'll be using JPCT.

I will be basing my game on the classic Stunt Car Racer:



I'll update on how it goes and when my site is up.

A question though... I would like my landscape to be sun-lit (i.e from a distance and static) what would be the way to do this?

Also how is texture repeating set so it isn't streched over the whole landscape?

[EgonOlsen]

A question though... I would like my landscape to be sun-lit (i.e from a distance and static) what would be the way to do this?

I can imagine three different solutions to this problem:
1.) Code the lighting information into the texture. This may produce nice results in some cases, but to be honest i doubt that will in your case.
2.) Use the normal lighting jPCT offers. Place the "sun" in the distance and play with the lightMul, linearDiv and fadeOutLight parameters in Config. Maybe it's possible to produce the desired effect this way.
3.) (and this is NOT possible at the moment but something i'm still thinking about)...use a kind of simple VertexShader-Interface to implement some things on a vertex-level for yourself. Problem with this is, that i have to find a logical, convenient and fast way of doing this and that isn't that easy. Anyway, it won't help you much hear me talking about features that may come in the future...

So i suggest to go with the dynamic lighting jPCT offers. If it really doesn't work, please let me know where the problem is...maybe i can do something about it.

Also how is texture repeating set so it isn't streched over the whole landscape?

That's not possible, because that would hurt the software-renderers performance too much. If you really need it, do the modulo-calculation by yourself on the texture-coords (before calling addTriangle()). But that will require that you build the object by yourself (i.e. not using one of the loaders in Loader). IF the vertex-shader-stuff mentioned above would be in jPCT, it should be possible to do such things in a more convenient way...IF.... :wink:

BTW: I loved stuntcar racer. It was a great game to be played via a (null-)modem connection.

[Neoteric]

I can imagine three different solutions to this problem:
1.) Code the lighting information into the texture. This may produce nice results in some cases, but to be honest i doubt that will in your case.
2.) Use the normal lighting jPCT offers. Place the "sun" in the distance and play with the lightMul, linearDiv and fadeOutLight parameters in Config. Maybe it's possible to produce the desired effect this way.
3.) (and this is NOT possible at the moment but something i'm still thinking about)...use a kind of simple VertexShader-Interface to implement some things on a vertex-level for yourself. Problem with this is, that i have to find a logical, convenient and fast way of doing this and that isn't that easy. Anyway, it won't help you much hear me talking about features that may come in the future...

So i suggest to go with the dynamic lighting jPCT offers. If it really doesn't work, please let me know where the problem is...maybe i can do something about it.

Number two was the one I was heading for, didn't realise there were lightMul, linearDiv and fadeOutLight peramiters, I haven't gone through all the documentation yet. Either that or I can try and calcualte the normals and shading myself, which I don't really have time to do at the moment.

That's not possible, because that would hurt the software-renderers performance too much. If you really need it, do the modulo-calculation by yourself on the texture-coords (before calling addTriangle()). But that will require that you build the object by yourself (i.e. not using one of the loaders in Loader). IF the vertex-shader-stuff mentioned above would be in jPCT, it should be possible to do such things in a more convenient way...IF.... :wink:

BTW: I loved stuntcar racer. It was a great game to be played via a (null-)modem connection.

Yeah, that makes sense. I guess I could piece togeather the landscape into a patch work so the texture is split into smaller areas, shouldn't have too much impact on the over all speed and also very simple.

...that reminds me I have to give the OGL version a go.

I downloaded SCR on an emulator a while ago, can't get enough of it. If I get off the ground with this hopefully my stunt car racer will be upto 6 player over TCP/IP, I won't get around to implementing that until after the physics though (obviously) and that when my universtiy work is out the way.

Thanks for your time.

[Neoteric]

And another question. I'm fairly new to 3D graphics so how big can I expect to make a level for a first person game? Especially if it was again spread across a large landscape again, including collision detection, interiors and perhaps lights, can the engine cull fast enough with a view frustum etc? or should I opt for a scrolling tile basis?

Something like the Project IGI engine is what I have in mind.

[EgonOlsen]

Good question. jPCT's design is targeted to be a game oriented but versatile 3D engine while maintaining a reasonable size (of the jar) and i added some optimizations (i.e. the portal stuff) for indoor rendering. For large outdoor scenes, a quad- or octree would be more usefull (and maybe ROAM...), but even then...it's still Java. As much as i like Java, the fact remains that it isn't the fastest language around. I may add an octree implementation one day (at least it's on my list of "maybe-i-should-do-this" things) but i'm not sure if this would make something like Project IGI  possible. No one ever tried to do something like this in Java so there are no references. I believe that a lot more is possible with jPCT than i can think of at the moment (i'm always wondering what people are doing with the engine...it's everything but usually not what i have in mind when i'm programming... ).
About the frustrum culling: jPCT uses frustum culling on a per sector (for portal rendering), per object and finally per polygon base. It may help to split a terrain like in IGI into objects...which is a rather unlogical approach but it *may* work. Just a thought....

BTW: I had a look at your email-address. Are you the guy who wrote this raycasting applet with the slightly wrong rendered floors?

[Neoteric]

BTW: I had a look at your email-address. Are you the guy who wrote this raycasting applet with the slightly wrong rendered floors?

Afraid so, how did you know that?  :shock: Think I'll leave the 3D graphics to the experts in the future, what annoys me most is i've actually got it to work before back on my old Amiga, I'll have to plug it back in and find out how I did it.

Got to get around to fixing that this weekend. I think the problem is with the fisheye on the walls rather then the floor, can't for the life of me work out what though. I must just be calculating the wrong ray components. Notice the walls squash at the far sides of the screen.

EDIT:I've just replaced the current version with a more optimised one.

http://www.omegaruins.com/projects/VrTour/popup2.html

[Neoteric]

Finally that problem is fixed.

http://www.omegaruins.com/projects/VrTour/popup3.html

[EgonOlsen]

Yes...it's looking fine now. Is there a way to show the framerate or am i just blind?

[Neoteric]

Yes...it's looking fine now. Is there a way to show the framerate or am i just blind?

I haven't put a frame counter in yet, I'll put shading in soon if I can find a cheep way to do it, will need to know the frame rate then.

Providing it runs smoothly enough I'm not too worried.

[EgonOlsen]

I haven't put a frame counter in yet, I'll put shading in soon if I can find a cheep way to do it, will need to know the frame rate then.

Providing it runs smoothly enough I'm not too worried.

Funny...a frame counter would be the first thing to put in for me...
Even if nothing else happens: I just have to know how fast this "nothing else" happens  
About the IGI-question again: I'm currently working on a octree-implementation for jPCT. That doesn't mean that something like IGI will be possible though, but it may ease the task somehow. Anyway...my current implementation lets you add an octree to an object in a single line of code, so even if it doesn't help, it doesn't hurt either.

[EgonOlsen]

About Stuntcar Racer...i just discovered this one. Have a look:

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=02-10-2003&forum=iotd&id=-1

[Neoteric]

Funny...a frame counter would be the first thing to put in for me...
Even if nothing else happens: I just have to know how fast this "nothing else" happens  

Usually for me too, optimisation freek here as well. Apart from removing a few square roots (been a bit lazy there) there isn't much I can do to improve the speed, there must be a few Java tricks I don't know of.

I don't want to use tables because the accuracy is needed. The thing that would improve speed the most would be to find a way to wrap the floor texture faster, right now every pixel needs a mod. I could keep track of the u,v values and only mod when necessary but haven't really thought about that.

About the IGI-question again: I'm currently working on a octree-implementation for jPCT. That doesn't mean that something like IGI will be possible though, but it may ease the task somehow. Anyway...my current implementation lets you add an octree to an object in a single line of code, so even if it doesn't help, it doesn't hurt either.

For really massive RPG/flightsim landscapes I guess it would need to be scrolled/patch-worked anyway. Doing the detail textures/blending in software necessary for good landscapes seems a little ambitious, might have to wait for the full opengl release before I can think about implementing one.

Individually texturing the polygons has been deprecated in jpct, would you not reccomend that? Because it seems the only way to do landscapes properly.

About Stuntcar Racer...i just discovered this one. Have a look:

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=02-10-2003&forum=iotd&id=-1

Hehe, that's nice. Hasn't got the banked track right and it's too thin but the engine is pretty good. The plan is in mine to interpolate the track using Bezier curves and give it a better flowing shape.

[EgonOlsen]

Individually texturing the polygons has been deprecated in jpct, would you not reccomend that? Because it seems the only way to do landscapes properly.

It's still possible to texture the polygons individually when adding them. What is deprectaed is the possibility to change a polygon's texture AFTER adding it. The reason for this is the same i mentioned above while talking about the "vertex-shader"-stuff: The number of a polygon after adding it is not always the number it had when adding it, because jPCT optimizes the meshes (or call createTriangleStrips() and the whole mesh will be re-ordered). Maybe it's a good idea to allow some kind of IDs for polygons...we'll see....

[Neoteric]

Individually texturing the polygons has been deprecated in jpct, would you not reccomend that? Because it seems the only way to do landscapes properly.

It's still possible to texture the polygons individually when adding them. What is deprectaed is the possibility to change a polygon's texture AFTER adding it. The reason for this is the same i mentioned above while talking about the "vertex-shader"-stuff: The number of a polygon after adding it is not always the number it had when adding it, because jPCT optimizes the meshes (or call createTriangleStrips() and the whole mesh will be re-ordered). Maybe it's a good idea to allow some kind of IDs for polygons...we'll see....

Ah i get it, I still don't know much about vertex shaders, if you know of any good papers on the subject I'd like to take a look.