03-12-2010, 08:18 PM,
|
|
portets
Member
|
Posts: 152
Threads: 12
Joined: Apr 2009
|
|
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?
|
|
03-13-2010, 05:53 AM,
|
|
NaN
Posting Freak
|
Posts: 2,024
Threads: 120
Joined: Jan 2010
|
|
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.
|
|
03-13-2010, 06:33 AM,
|
|
NaN
Posting Freak
|
Posts: 2,024
Threads: 120
Joined: Jan 2010
|
|
Here something to tease you.
Laguna Seca in February:
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.
|
|
03-13-2010, 06:41 AM,
|
|
portets
Member
|
Posts: 152
Threads: 12
Joined: Apr 2009
|
|
NaN Wrote:Here something to tease you.
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 . 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 . 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: http://fireuser.com/blog/opengl_release_...aves_the_/
|
|
03-13-2010, 09:43 AM,
|
|
NaN
Posting Freak
|
Posts: 2,024
Threads: 120
Joined: Jan 2010
|
|
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.
|
|
03-13-2010, 11:49 AM,
|
|
portets
Member
|
Posts: 152
Threads: 12
Joined: Apr 2009
|
|
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.
|
|
03-13-2010, 02:17 PM,
|
|
sebiastisch
Junior Member
|
Posts: 30
Threads: 3
Joined: Feb 2010
|
|
What do you think about Open Scene Graph?
It looks good, is stable, fast and easy to use (and to combine with bullet )
|
|
03-14-2010, 02:51 AM,
|
|
portets
Member
|
Posts: 152
Threads: 12
Joined: Apr 2009
|
|
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! 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.
|
|
03-14-2010, 04:44 PM,
|
|
joevenzon
Administrator
|
Posts: 2,679
Threads: 52
Joined: Jun 2005
|
|
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:
http://diaryofagraphicsprogrammer.blogsp...derer.html
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: rawScene 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.
|
|
03-14-2010, 07:00 PM,
|
|
portets
Member
|
Posts: 152
Threads: 12
Joined: Apr 2009
|
|
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.
i actually made my road texture for rouen.
edit: changed post because i just found the difference between normal and bump maps.
|
|
|