Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
VDrift Graphical Upgrades
03-12-2010, 03:35 PM
Post: #1
RE: VDrift Graphical Upgrades
i think, maybe just up the minimum spec of vdrift to more modern hardware, and focus on high end graphics boards and systems and forget the older rendering pipelines.

maybe good to do some polls to see system specs of users: just cpu, ram, graphics card are probably enough. maybe os version for the word-size of the windows. hmm i wonder if there's anyway to add those fields to the forum account. so they could be queried easily.
Visit this user's website Find all posts by this user
Quote this message in a reply
03-12-2010, 08:18 PM
Post: #2
 
i think it's a good idea, we could start a new thread. not alot of people go here so i could ask at different forums.

but right now the vdrift focus (judging by the work going into svn lately) seems to be physics realism. and bug fixing of course. so i doubt much work will go into pretty graphics right now. (i am not a dev, and i can be entirely wrong).

i still think it would be a great idea to find out the user bases computer specs anyway though. depending on our specs, joe and his contributors will know how many shortcuts they have to take in physics code, or not. and later on, graphics code.

lately i've been wanting to ask on a forum if anyone would like to help out on vdrift's graphics system. does vdrift use openscenegraph? and shaders are coded in glsl?
Find all posts by this user
Quote this message in a reply
03-13-2010, 05:53 AM
Post: #3
 
Vdrift is using a custom scene graph implementation. It has a fixed-function fallback. The minimum requirement for shaders is GLSL 1.2.

I've been thinking about moving to a graphics engine like Ogre or Irrlicht after I am satisfied with the simulation part of the game.
This would require some serious code refactoring. Hopefully I will find the time and motivation to do it. Smile
Find all posts by this user
Quote this message in a reply
03-13-2010, 06:33 AM
Post: #4
 
Here something to tease you. Big Grin

Laguna Seca in February:
[Image: sky31r3r.jpg]

The parameters file looks like this at the moment:
Code:
longitude = -121
latitude = 36
azimuth  = 270                # track mesh orientation (+z-axis(-y-axis in blender) is north)
timezone = -8
time = 2010-02-10 15:20:00    # local time
turbidity = 2                # atmosphere turbidity 1 - 10 (depends on location, season)
exposure = 2                # has to be adjusted manually atm
overcast = 0                # 0-10? (to be implemented)

It's a Nishita style atmospheric scattering sky box(quad).
I've got the code since February. Just haven't had the time to integrate it properly into the game.
Find all posts by this user
Quote this message in a reply
03-13-2010, 06:41 AM
Post: #5
 
NaN Wrote:Here something to tease you. Big Grin

Laguna Seca in February:

It's a Nishita style atmospheric scattering sky box(quad).
I've got the code since February. Just haven't had the time to integrate it properly into the game.

ooooh. nice, NaN. is that info stored in the track file?

NaN Wrote:I've been thinking about moving to a graphics engine like Ogre or Irrlicht after I am satisfied with the simulation part of the game.
This would require some serious code refactoring. Hopefully I will find the time and motivation to do it.

i was actually thinking about ogre recently. i've seen some really nice looking games using ogre Smile . one was a racing game. (actually a vehicle stunt game that was proprietary).

ogre has opengl 3.2 support i think. and it probably won't be long before ogre has opengl 3.3 support and opengl 4.0 support.

oh, by the way everyone. opengl 3.3 and 4.0 were released a couple of days ago. 4.0 seems to be very, very nice Big Grin . it requires a directx 11 card capable of hardware tessellation. and 3.3 tries to backport a bunch of 4.0 features for directx 10 capable cards. opengl 2.1 is starting to become part of the past.

edit: also, glsl jumped from version 1.5 all the way to version 4.0!
edit2: In order to view links, you must have to reply to this thread.
Find all posts by this user
Quote this message in a reply
03-13-2010, 09:43 AM
Post: #6
 
Quote:ooooh. nice, NaN. is that info stored in the track file?

It's a separate sky.txt file right now(I kinda hacked it into vdrift).

I implemented it as a shader. It can be(is going to be) updated in real time(like every 10 minutes). Think of 24h races.
Find all posts by this user
Quote this message in a reply
03-13-2010, 11:49 AM
Post: #7
 
cool. will it also change the shadow position and sun reflecton of the car?

even if it doesn't, it would make for some cool sunset driving.
Find all posts by this user
Quote this message in a reply
03-13-2010, 02:17 PM
Post: #8
 
What do you think about Open Scene Graph?
It looks good, is stable, fast and easy to use (and to combine with bullet Smile )
Find all posts by this user
Quote this message in a reply
03-14-2010, 01:30 AM
Post: #9
 
Don't worry, the fixed function fallback for people with older cards isn't holding back the development of fancier graphics.

What sort of graphical features do you think people would like to see in VDrift?

I think some the most obvious improvements to graphics would require a lot of artist work on new assets: high poly car models with normal maps, higher res track textures, baking ambient maps for the tracks, normal maps and specular maps for tracks, and so on.

I don't see much benefit to switching to OSG or ogre, except for maybe a couple of flashy shader effects that ogre comes with.
Find all posts by this user
Quote this message in a reply
03-14-2010, 02:51 AM
Post: #10
 
joevenzon Wrote:What sort of graphical features do you think people would like to see in VDrift?

well, i think bump mapping would be amazing!Big Grin but i understand that's kind of unfeasible. probably a lot of work to do that. the only other two things that i can think of have been said already. those are dynamic reflections back and motion blur. i'm starting to not want motion blur though, but that's just me. other people probably do.
actually.... it'd be nice to have exhaust flames. (realistic ones, not arcade-style). and different effects for different surfaces, like grass and sand.

joevenzon Wrote:I think some the most obvious improvements to graphics would require a lot of artist work on new assets: high poly car models with normal maps, higher res track textures, baking ambient maps for the tracks, normal maps and specular maps for tracks, and so on.

i've been experimenting with importing cars into blender and trying to raise poly count. i haven't made any look better but i'm getting close. i've also tried making some higher quality textures for cars. (just minor stuff). i've made a new road texture. it's 4096x4096 instead of 512x512. and it's 39.7 mb compressed vs 526.7 k for the previous texture! i'm going to have to lower the quality of it. it's 166.4 mb uncompressed. also, about the different surface effects, i'd be willing to make dust textures and sand-spray textures. grass too.

when i get the enzo imported i'm looking at getting it down to 30,000 faces because any lower, it looks bad. i'm also working on an electric car. (my first blender model). i already made a new electric motor sound in audacity and tuned the .car file. all i need to do is detail the model.
oh, and the electric car is my own design.
Find all posts by this user
Quote this message in a reply
03-14-2010, 09:08 AM
Post: #11
 
I'd like to have soft particles(spherical billboard), multiple lights and HDR rendering(no I don't mean bloom). => I'd like to have a decent deferred renderer.

Right now we have things like SetSmoke(), SetSkybox(). What if I have an alternative particle/skybox implementation/shader. How do I integrate it into the scene graph?

If you look at my sky rendering integration in the bullet branch. It's an ugly hack right now. I still haven't figured out how to add it to the scene graph in a clean way.
Find all posts by this user
Quote this message in a reply
03-14-2010, 04:44 PM
Post: #12
 
NaN Wrote:I'd like to have soft particles(spherical billboard), multiple lights and HDR rendering(no I don't mean bloom). => I'd like to have a decent deferred renderer.

VDrift already does HDR rendering (I don't mean bloom), but it uses a very simple tonemapping that's local to the pixel. It could definitely be improved. I was looking at implementing Wolfgang Engel's light pre-pass renderer. It allows for easier antialiasing than most other types of deferred renderers. See:
In order to view links, you must have to reply to this thread.

What sort of other light types and sources do you think we need? For night time driving there are several, but I can't really think of anything to add for daytime driving, except maybe in tunnels.

I think a better material system is needed too. Right now there are a few parameters set in the texture, but they just aren't general enough to work for many surface types (as MirceaKitsune has found).

Quote:Right now we have things like SetSmoke(), SetSkybox(). What if I have an alternative particle/skybox implementation/shader. How do I integrate it into the scene graph?

If you look at my sky rendering integration in the bullet branch. It's an ugly hack right now. I still haven't figured out how to add it to the scene graph in a clean way.

The scene graph system needs a little bit of work, but it's a pretty good base. Here's how integrating something like your dynamic skybox would work:
* load your new shader in GRAPHICS_SDLGL::EnableShaders
* add a new shader type in the GRAPHICS_SDLGL::RENDER_INPUT_SCENE::SHADER_TYPE enum
* add a property to the DRAWABLE class if needed (we already flag skyboxes so you may not need to do anything for the case of your skybox code)
* make sure your DRAWABLE instance gets marked with the property you added (for skyboxes, this happens via the track's objects/list.txt file and the code in TRACK::OBJECTLOADER::ContinueObjectLoad)
* in GRAPHICS_SDLGL::DrawScene call renderscene.SetShader(RENDER_INPUT_SCENE::MY_SHADER_TYPE, shadermap["my_shader_name"]);
* upload any per-frame parameters to the shader in GRAPHICS_SDLGL::RENDER_INPUT_SCENE::Render
* add code to GRAPHICS_SDLGL::RENDER_INPUT_SCENE::SelectAppropriateShader to enable your shader based on the DRAWABLE property you added

I want to fiddle with the code some to make it easier to manage shader types, render passes, and shader constants. Also, right now there are a lot of really huge function bodies that I'd like to simplify.
Find all posts by this user
Quote this message in a reply
03-14-2010, 04:49 PM
Post: #13
 
portets Wrote:i think bump mapping would be amazing!Big Grin but i understand that's kind of unfeasible. probably a lot of work to do that.

No, that's actually pretty easy on the code side, it's just that someone has to actually go and make all of the normal maps. :-)

Quote:i've made a new road texture.

You know, if you're up for it, we should all collaborate on making Rouen prettier. It's a public domain track, so it's no problem for us to modify it any way we want.
Find all posts by this user
Quote this message in a reply
03-14-2010, 04:50 PM
Post: #14
 
FYI I've moved this thread out of the unreal development kit post and into its own post.
Find all posts by this user
Quote this message in a reply
03-14-2010, 07:00 PM
Post: #15
 
joevenzon Wrote:No, that's actually pretty easy on the code side, it's just that someone has to actually go and make all of the normal maps. :-)

aww. i thought a normal map was a synonym for a bump map. normal maps look pretty hard to create by hand. :?
i don't have the blender skills for that.

Quote:You know, if you're up for it, we should all collaborate on making Rouen prettier. It's a public domain track, so it's no problem for us to modify it any way we want.

hehehehe. Big Grin
i actually made my road texture for rouen.

edit: changed post because i just found the difference between normal and bump maps.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)