| Wednesday, September 27, 2006 |
  Galactos eye-candy | 
Posted - 9/27/2006 10:12:11 AM | Same than the Flamberge ( see previous journal for details ), but this time for Kaboom22's Galactos, a carrier.
I didn't precise it yesterday, but the texturing is extremely basic. I received the model untextured, only the geometry. I applied a box mapping on the whole model and used Juan's generic buildings textures. I selected a few polys that were fitting more or less well as windows, and applied a second texture. Therefore, the whole ship you saw yesterday ( and the new galactos ), use 2 generic textures and simple box mapping for tex coords. No more than one hour of programmer art-work :)
I couldn't resist the temptation to put the Galactos and the Flamberge in the same scene, just to compare their size. It's pretty funny, the galactos appears so big on the details ( 4 first screens ), yet it appears so small compared to the Flamberge ( 2 last screens ) :)
Click to open the images in fullscreen (1024x768 AAx4):
 
 
 
| |
| Tuesday, September 26, 2006 |
| Flamberge eye-candy | |
Posted - 9/26/2006 5:40:05 PM | A journal update dedicated to eye-candy screenshots! Yeay. No long technical description :)
Don't hold your breath: the final game should look even better. Mostly missing are the fresnel reflections of the environment and some ambient occlusion ( local, smooth shadows ).
I had to fine tune all the parameters so that it looks good in the screens. I'm not sure yet how i'm going to handle all those different models / lighting in the final version, as it seems so far each model requires tweaking to look good.
Finally, the framerate is abysmal. As mentioned in my previous update, GPUs do not support HDRI + FP16, and my RGBE code path doesn't support shadows yet. In order to make a "best quality" possible, i had to reuse the old fp16 code, so antialiasing is done by supersampling a x4 times bigger buffer, ie. render to a 2048x1536 texture. Since the bottleneck is mostly in the shaders, the framerate goes in the 10-15 fps range on my ATI; on my NVidia card ( 7800 GT ), it's a lot better, around 40-45 fps, but that's still not very good for a single ship.
The ship is around 100K triangles and was modeled by Supernova. All i can say is, it's an incredible work. Perfect modeling, no smoothing problems, no mesh errors, and an insane quality/balance of details. Along with Jack's Trireme/remora, it's probably the best ship i've seen so far. I almost had a tear on my eye when i saw it the first time :)
Note the Culverine, a 20 meters long corvette hovering over the Flamberge. Feels small, heh ?
Click to open the images in fullscreen (1024x768 AAx4):
 
 
 
| |
| Monday, September 25, 2006 |
| On HDRI, OpenGL and stuff.. | |
Posted - 9/25/2006 5:36:59 AM | HDRI and Blooming
I realized that my implementation of the bloom effect was wrong. It seems like in a lot of litterature on the net, white papers or even gpu presentations, one has to run a bright pass filter on the raw fp16 buffer, blur it a few times, then add it back to the scene, and then apply tone mapping.
And then i was wondering why in some of my scenes, i had very bright areas that didn't bloom.
Well, that's logic: the bloom effect should come after tone mapping. The more i think to it, the more it makes sense: by tone mapping, you're basically remapping the brightness range from HDR to [0-1] so that it's displayable on your monitor. The areas on your screen that bloom, are the areas that end up with values higher than 1 after tone mapping; not before.
An example: let's say that i have a very dark scene, most values being in the [0-0.1] range, but i have a small area that has a 0.2 color. After tone mapping, this area will end up being very bright and should bloom. If blooming is applied before tone mapping, the bright pass filter will discard a value as small as 0.2, and there will be no bloom..
So, i fixed the problem simply by adjusting the pixel shaders and reorganizing the code a bit.
I have integrated the "prototype" code as an HDRI render pipe into the engine.
Shader preprocessor
ATI cards do not support the automatic shadow mapping depth comparison test in a pixel shader, you have to implement it yourself with a CMP/SGE instruction. On the other hand, NVidia cards do support this shadow map test, and even have hardware PCF. I found myself having to comment/uncomment lines in my pixel shaders every time i was switching between a system having an ATI card, and another one having an Nvidia card ( and i do that often, at least twice a day ).
Of course, i could duplicate the shader ( ie. have one version for ATI and another one for Nvidia ) but.. that's overkill only for 2 lines of difference.
Instead, i choose to implement a shader preprocessor. It's similar to the compiler preprocessor you have in C/C++: i have added #ifdef / #ifndef / #else / #endif instructions, that are independant of the type of vertex or pixel shader to compile ( ie. it's done by the engine while loading the source code file ). The conditional variables can be set in the engine config, for example when initializing OpenGL, i detect if the vendor string contains "ATI" or "NVidia", and this later allows me to write:
#ifdef GPU_ATI
... code for ATI ...
#else
... code for anything else ...
#endif
... in my shaders. Simple and very useful.
A rant on OpenGL:
Yes, that time of the year, my yearly rant on OpenGL.
I'm having enough of OpenGL, and will switch to DirectX9/10 progressively.
OpenGL is nice and all for portability or for its "clean" core API when you're a beginner. But having more than 300 extensions is a nightmare, especially when those extensions don't interact very well with each other.
The ARB ( making specifications/extensions for OpenGL ) ( and i particularly blame ATI and Nvidia ) has a philosophy of "let's make an extension that is the minimum common thing supported on our video cards" and "anything else, we'll bother later by adding new extensions".
What does this lead to ? An FBO extension that doesn't even support anti-aliasing, ie. that is useless for your average game developer that is not ready to sacrifice AA for a few render-to-texture effects.
The hardware supports it. DirectX9 supports it. Hell, DirectX9 has been released in 2002. Four years ago. Oh, yes, a GL_EXT_framebuffer_multisample extension has recently been released, but since nobody is supporting it yet.. see what i mean ? Instead of releasing an FBO extension that contains everything, and then if the hardware doesn't support it you get an error, you've got an extension for FBO, then an extension for FBO + antialiasing, and then an extension for FBO + antialiasing + FP16 buffers. What's next ?
In the mean time, the old PBuffers extension still works, but unfortunately, ATI X1800 cards do not report any antialiased pixel format with fp16 while their hardware and DX9 can do it.
On RGBE:
In my quest for optimizing performance ( and hopefully getting anti-aliasing to work with HDR ), i experimented the RGBE pixel format. The idea is to use a fixed point, standard 32-bits RGBA buffer instead of a 64-bits fp16 one, and to encode the color and brightness in high dynamic range into the RGBA channels. It takes 3 asm instructions to convert RGBE to RGB inside a pixel shader, but the encoding is a bit more complex ( currently takes 11 asm instructions ). One problem is the use of the "ceil()" instruction which is not available in asm, so i had to emulate it with the "floor()" instruction instead. I wonder if in GLSL this instruction is native or uses a similar trick.
I'm of course loosing performance due to encoding/decoding in every stage of the HDRI pipeline, but on the other hand i'm saving 50% bandwidth and video memory, and i can (potentially) get antialiasing since i'm rendering to a standard fixed point texture.
Zedzeek mentioned the Logluv format and i had a look at it, but unless i'm missing something, the encoding/decoding requires a lot more instructions than RGBE, so its interest looks pretty limited to me.
| |
| Wednesday, September 13, 2006 |
| HDRI + shadowing + cities | |
Posted - 9/13/2006 3:06:42 PM | Today, two new videos for the price of one !
On HDRI:
I have finally implemented automatic exposure by downsampling the scene recursively until i get a 1x1 pixel that contains the scene luminance. I have two implementations: a simple average, and Reinhard's operator. The first one is fast and looks pretty good. The second one is supposedly more accurate, but requires more pixel shader instructions, and at the moment its advantages are not clear compared to a simple average. Needs more experimentation.
Once the scene luminance is stored in a 1x1 texture, i interpolate this texture with the "current" luminance. This makes the luminosity adapt over a short period of time ( currently set at one second ), rather than being instantaneous. If you go in a dark area and quickly look at the sky, everything glows. It's magic !
Speaking of glows, i am now downsampling and blurring the scene multiple times ( previously, i was doing it only once, meaning the pixels range the bloom could affect was limited ). Doesn't cost too much performance. I'm also performing the blur in a standard, fixed point RGBA 8 bits texture, instead of using a FP16 buffer. It's faster, and i can make use of bilinear filtering to have an even better blur. The downside is that the values are clamped to [0-1], but it's possible to work around this "problem" by playing with the parameters.
On Shadows:
In one of my previous journal entries ( 6 months ago ? ) i was speaking of assigning a shadow map for each object. I dropped this technique in favor of cascaded shadow maps. It seems like cascaded shadow maps offer the best performance/quality trade off. At the moment, i'm using 2 levels of shadow maps ( each 2048^2 ), but i'm planning to add more once everything feels "right".
In order to get good transitions between the two shadow maps, i had to implement.. orthographic projections. Previously, i was using a perspective frustum with an apex set very far away ( to reduce the distortions due to perspective ) and a very big near clipping plane distance. Because there was two different shadow maps each with their own frustum, the perspective distortion prevented the shadows of one map from matching with the other one. Disturbing.
Now, with orthographic frustums, everything is good. I spent my whole week end on this implementation, mostly lost in debugging, since i forgot the fact that my matrices were setup in the DirectX way rather than the OpenGL way ( which i'm using for rendering ). Of course, checking the ortho projection matrix and comparing it to the one built in OpenGL, i did not find any difference.. except that it was expecting the ortho matrix the way it's built in DirectX. Ah Ah.
The two shadow maps are centered on the camera and are moving with it. It causes the shadows to flicker. I fixed that by transforming the shadow maps origin into object space, round this position to the shadow map texel size, and transform it back to world space. No more flickering. Except when the light itself moves, but there's nothing i can really do to help.
Shadow maps ( actually, the closest level only ) are antialiased - not really "soft" shadows, but the effect is cool. On NVidia cards, it's very nice, thanks to hardware PCF. On ATI cards it's less nice, even sampling the shadow map 8 times. The performance hit is... important.
I still have to improve shadows in the future. One thing i want to try is to store the shadow maps in an "atlas" texture, a single 2048^2 that will contain 4 1024^2 shadow maps. Four levels of shadow maps, even at half the resolution, might look better than what i currently have on two levels. It should also allow me to antialias all the levels. It should be lighter on memory and performance, since there's no need to render to 4 separate textures; only adjust some texture coordinates in a shader to write to or read from a specific quarter area, and it's done. Or, at least, i hope so..
Shadow maps are not updated every frame, but only every 4 or 8 frames ( respectively, for the two levels of shadow maps i currently have ). The largest shadow map is just enough to cover the whole city ( see video ).
On LOD ( level-of-detail ):
I spent a few days improving the current metrics. Nothing really important to say, it's very technical and mostly related to debugging and understanding why, sometimes, some silhouette edges are moved.
New videos:
Disclaimer: keep in mind this is a work in progress. Yes, it's not perfect. There are tons of little problems, parameters to adjust. Things will improve over time. And keep in mind it's yet another "tech" demo: even if it looks nice, it's far, extremely far from being more than a rendering prototype.
City video ( 45.8 MB, Divx5 ) : showing off the city and a few models. Stannum's buildings, Shawn's city dome ( a draft - yeah, textures are really deformed, it will be fixed. Same for the "metallic grid" on the roof ), CutterJohn's Intrepid, and 100 Shadix/Petrov interceptor's loaded ( to have any idea of the slowdown due to traffic ). Also shows HDRI and dynamic shadows.
Spuk's outpost : showing off the small station made by Spuk. Generic textures, no skybox/background, it's a bit plain, but it shows HDRI + dynamic shadows. Interior not shown due to backface culling problems in the model.
Mandatory screenshots:
| |
| Saturday, September 2, 2006 |
| Various updates | |
Posted - 9/2/2006 2:55:53 PM | On nebulae:
I've been lazy last week. I only finished the implementation of planetary nebulae. Technically, nothing fantastic: it's just a matter of normalizing each point, and the lerp-ing the point's original position with the normalized position by a constant factor, which i called the "spherical factor". When this parameter is 1.0, all the points end up on the surface of a volumetric sphere, the emitting star being its center. When the parameter is 0.0, you get the "old" nebulae.
I also spent a bit of time to optimize performance for the cloud point generation and operations, like lighting. No spectacular speed up, but every little gain is welcome.
On simplex noise:
Natume mentionned on the forums that simplex noise can be faster than improved Perlin noise ( what i'm using in Infinity so far ). Unfortunately, the results i've measured show the contrary ( at least in 3D ), my own improved noise implementation being a lot faster than simplex noise, and i've tested on 3 different configs ( see the thread above ).
If anybody's got a working version of simplex noise that is running much faster than improved noise, please let me know and/or send me the code.
On people, part I
I have noticed an increasingly annoying trend in the past weeks, which is to disturb me or to ask me mundane questions. I'm getting a lot of emails that ask me questions who have direct answers in the F.A.Q. I'm getting a lot of people on IRC asking me what i'm "up to", what i'm doing ( hint: if i bother maintaining a dev journal, it's to avoid loosing too much of my time explaining to different people what i'm doing ) ; or even contributors who've added a bunch of details to their work and want some feedback. I somewhat feel guilty about it, and believe me, i would really love to spend hours to chat with everybody and to give feedback on everything, but the community's growing quite a bit recently and i find myself loosing hours just answering emails or questions on IRC.
So, from now on, any mundane question will be strictly ignored, and you will get ignored if you PM, email or irc me with such questions. If you have to ask me a question, the first thing you should ask yourself is: "is Flavien the only one who can answer ?". If the answer is no, *please* do not disturb me. There are other devs on irc you know, and if all devs are busy, there are other people or contributors who stay on irc all day.
On people, part II:
Another annoying trend, at least to me, are people who suggest ( sometimes quite innocently ) that feature X or Y should be implemented in Infinity. For instance, today Darknos PMed me with a suggestion to use Navier Stokes equations for fluid dynamics in order to simulate oceans on the planets. Wouldn't it be fantastic to have water that have proper waves and reacts to your ship when you fly over the surface ?
Hell yes. Will that be implemented ? Hell no.
You see, there are a lot of features that would be cool to have. The "todo" list is already very long. It would not be wise to add more to it right now, as i'm already going to be busy in the coming 2 years with the currently planned features. In addition, it's common sense that any feature requires some work to be implemented, so if something has no consequence on the gameplay ( or if it's graphics related, like this water discussion, if it's something that people usually won't see or experience ), it's simply wasted time.
So, please refrain from posting things such as "Infinity should have this or this feature".. it's causing me stress, especially when i think of all the hard work needed for the current list, and that it's unlikely to happen.
In the same idea, please keep in mind that all images i post on the website, unless otherwise specified ( like the nebulae, when i say it's considered "done" ), are work in progress.
On HDRI (high dynamic range)
I have started to write the render pipeline for HDRI. Nothing special to say. Lots of render to texture, many typos / bugs fixed, a few more subtle bugs fixed, overall it's going smoothly.
The main things worrying me with HDRI are:
- no antialiasing ( any idea on how to support antialiasing with HDRI in OpenGL ? )
- cannot rely on blending ( thanks ATI )
- cannot rely on the alpha test ( thanks NVidia )
- cannot rely on texture filtering ( thanks to both )
I still have to improve the bloom quality ( better blurring ), and to make exposure a function of the image brightness ( at the moment the exposure is manual and can be changed with a pair of keys ).
On cities:
Stannum uploaded two buildings, with are made of many sections each. I'm not sure of the number of combinations, but it's pretty safe to say that it's in the order of thousands, maybe more. Now, two buildings only aren't enough to make varied cities, but at least all the buildings are "unique" and have subtle, but different details.
The buildings are procedurally spawned into the city. At the moment, nothing complex; each building is spawned on a grid, meaning everything is square ( too much ). In the future, I plan to generate main avenues and smaller streets and to spawn buildings near them.
Shawn is still working on a dome for large cities. Not all cities will have a dome, but it's necessary for those who are in space, or on planets with no (breathable) atmospheres.
New fleet render
Koshime has retouched the latest fleet render:
Click here to see it
| |
|
| S | M | T | W | T | F | S | | | | | | 1 | | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | | | | 28 | 29 | 30 | | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
October, 2009
August, 2009
July, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
November, 2008
October, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
September, 2005
August, 2005
July, 2005
June, 2005
May, 2005
April, 2005
March, 2005
February, 2005
January, 2005
December, 2004
October, 2004
September, 2004
August, 2004
|
