Development Blah

All other topics around Descent and D2X-XL

Moderators: Frustikus, simX, Aus-RED-5

User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Development Blah

Postby karx11erx » Tue Apr 15, 2008 2:15 pm

My attempts with Irrlicht have been rather disappointing so far, as I'd have to code a lot of rendering stuff myself because of the special requirements of Descent (e.g. many lights).

I am currently experimenting with per-pixel lighting in the current rendering engine. It works in principle, but I don't know how it will turn out in the end, looks like I will at least have to improve the light manager quite a bit. Currently it doesn't look too great.

One optimization that every player should benefit from is clustering related weapon shots (e.g. the four laser bolts from a super laser shot belonging together, or the pairs of Plasma or Phoenix shots) together in a single light source. I might take this a step further by generally grouping nearby dynamic light sources together to a single bright one.
Last edited by karx11erx on Wed Sep 17, 2008 1:13 pm, edited 4 times in total.
User avatar
Aus-RED-5
Forum Moderator
Posts: 1490
Joined: Tue Sep 25, 2007 9:02 am
Location: Adelaide, South Australia
Contact:

Postby Aus-RED-5 » Tue Apr 15, 2008 10:22 pm

Ah cool! 8)

Are you able to take any screenshots of this yet?? :mrgreen:
----System Specs----
Case: Corsair Obsidian 650D Black
Motherboard: ASUS Sabertooth X58
CPU: Intel Core i7 960 3.20ghz
Heat Sink: Corsair H100 CPU Water Cooler
Memory: Corsair 6GB (3 x 2048mb) DDR3 1600 Dominator (PC12800 - TR3X6G1600C8D)
Video Card: ATi SAPPHIRE Radeon HD 7970 3GB GDDR5 OC Edition
Hard Drives: SSD Corsair Force Series 3 F120 120GB & WD5003ABYX Enterprise RE4 500GB
Media Player: LG BH10LS30 BluRay Burner
Power Supply: Corsair HX-850
OS: Windows 7 Pro 64Bit
Monitor: Benq XL2420T LED
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Postby karx11erx » Tue Apr 15, 2008 10:30 pm

Nope. And I dunno yet whether it will ever work. Seems pretty slow right now.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Isch wer nochemol bleede, ey!

Postby karx11erx » Fri Apr 18, 2008 4:22 pm

My per pixel shaders just didn't work, and I couldn't figure why for the love of God ... until now!

Some background: If you render a scene, everything is relative to where the viewer looks. In other words: The viewer is always the point of reference. The relationship between 3D space coordinates and the screen is however fixed, so if the viewer changes his orientation (i.e. where he looks at), you have to move all vertices (stuff) around in space to change it's relation to the screen to make it look proper.

Now for per pixel lighting, you need the "normals" of the faces that are to be lit (a normal is a line perpendicular to a plane, or face). Of course, if you move the face around and probably rotate it somehow, you will have to adjust the normal accordingly.

All this rotating 3D coordinates is done by multiplying the coordinates with matrixes (X*Y tables of values).

GLSL (OpenGL Shading Language) has a comfortable matrix to rotate such normals which is called gl_NormalMatrix. It has another matrix to rotate regular coordinates (geometry or models) which is called gl_ModelViewMatrix.

Now comes the funny part: Using gl_NormalMatrix (which you are told to in every per pixel lighting tutorial around) doesn't work for me!? gl_ModelViewMatrix however does! :think:

This is so absolutely weird that it took me days to finally start to mess around with gl_NormalMatrix and gl_ModelViewMatrix because that was the last element of my per pixel lighting shaders I had not yet messed with in the hope to make it work. :rage:
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Postby karx11erx » Mon Apr 21, 2008 1:15 pm

Some new info: gl_NormalMatrix is working after all, there had been another mistake ... so I am getting closer to per pixel lighting. I am having a problem with the headlights that is really hard to come by though (not a mistake I am making, but rather a mathematical issue I cannot solve).
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Postby karx11erx » Mon Apr 21, 2008 9:49 pm

Some nice guy on the OpenGL.org forums gave me the right hint.

Descent has zoom and screen aspect factors and manipulates its 3D coordinate manipulation matrix (model view matrix) with it. The proper way to handle this with OpenGL is to manipulate the matrix that is used to compute the 2D screen coordinates (projection matrix).
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Postby karx11erx » Wed Apr 23, 2008 9:47 pm

The per pixel lighting code is getting better and better. Today I had a break through when finally figuring how to get around certain limitations and even bugs in the ATI driver. Still work to do, but I am closer, much closer now. ;)

The mesh optimizer doesn't always yield the kind of result one would expect though ... sometimes it confines light sources better to their actual radius, but that looks rather patched together due the raster the mesh presents. Oh well, it was a nice exercise anyway ... :)
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Postby karx11erx » Fri Apr 25, 2008 11:32 pm

Changed the lightmap creation code today to make it compatible with my per pixel lighting, and changed the per pixel lighting shaders to use lightmaps for static lights.

My biggest concern is whether I need to employ multi pass light rendering to make the levels look good with many light sources, and if so how to avoid saturation. Currently I can render up to 8 lights in a single pass, which I consider quite an achievement, having had to code around numerous driver bugs and limitations ...
User avatar
heftig
Posts: 29
Joined: Thu Feb 28, 2008 5:29 am
Location: Germany
Contact:

Postby heftig » Sat Apr 26, 2008 6:24 pm

Have you looked into deferred shading? It's another technique besides singlepass and multipass lighting.

http://ati.amd.com/developer/gdc/D3DTut ... hading.pdf
http://www.beyond3d.com/content/articles/19/

Deferred Rendering attempts to combine conventional rendering techniques with the advantages of image space techniques. In this article we separate lighting from rendering and doing so make lighting a completely image-space technique, this has some disadvantages but also some key advantages. These advantages include:
  • Lights major cost is based on the screen area covered
  • All lighting is per-pixel and all surfaces are lit equally
  • Lights can be occluded like other objects, this allows fast hardware Z-Reject
  • Shadow mapping is fairly cheap
The main disadvantages are:
  • Large frame-buffer size
  • Potentially high fill-rate
  • Multiple light equations difficult
  • High hardware specifications
  • Transparency is very hard
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Postby karx11erx » Sat Apr 26, 2008 7:54 pm

Ist mir viel zu aufwendig. Ich bin kein 3D-Guru der das alles aus dem Ärmel schüttelt. Ausserdem kannst Du Transparenz damit nicht rendern, das musst Du dann konventionell machen.

(I was too tired ...)

It's too much of an effort. I am not a 3D guru who could come up with something like that just so. Apart from that you cannot light transparency that way, you have to handle that conventionally.

As I can handle 8 lights per pass (which is quite a lot), and will use lightmaps for static (non-moving, indestructible, invariable) lights, the renderer should still work fast enough. For slower machines/graphics card people can still employ the mesh optimizer to achieve better lighting.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Postby karx11erx » Tue Apr 29, 2008 9:19 am

Got lightmap creation to work again, after having reworked it to make it fit with per pixel lighting. The original code was still from Lehm, and now I know enough about OpenGL to substantially improve it. I replaced the lighting calculation code Lehm had written by the OpenGL style lighting functions I had implemented later on, and that works like a charm, giving very realistic lighting, with specular highlights even. As a little bonus, you will be able to chose from 5 lightmap quality settings (ranging from very coarse 8x8 pixel lightmaps that get stretched over the surfaces, to very fine 128x128 lightmaps, which look really good).

Oh yeah. :clap:
Frustikus
D2X-XL Team
D2X-XL Team
Posts: 778
Joined: Mon Oct 22, 2007 3:06 pm
Location: Germany

Postby Frustikus » Tue Apr 29, 2008 2:28 pm

:joy: ---> :hug:

Ich kanns kaum abwarten bis ich das sehe ;-).

Ach und eine Antwort wie die meine ist kein :spam:
;-)
Intel Q9550 (E0) @ 3420 MHz and standard voltage with Sonic Tower Rev.2, Geforce GTX 260 (896 MB), Asus P5Q Deluxe, 6 GB GSkill DDR2-1066, 2x500 GB Seagate @ Raid 0, Soundblaster XFi, Sharkoon Rebel12 Case, Teufel Concept Magnum 5:1, Samsung 2494 SW , Genius Navigator 535, Logitech Wingman FF, Windows 7 Ultimate 64 bit
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Postby karx11erx » Tue Apr 29, 2008 2:42 pm

Frustikus wrote::Ach und eine Antwort wie die meine ist kein :spam: ;-)

Indeed, the reply is on topic. ;)

Btw, lightmaps are kind of "the poor man's per pixel lighting", where pixel light values are precomputed, using a more or less coarse grid, and the light values of the pixels inbetween are derived from the adjacent grid vertices when rendering the light map into the image.

So you have almost true to the pixel lighting w/o the cost - perfect to get static lights (i.e. those that never change) out of the way of the dynamic light calculation.
Sirius
Posts: 1987
Joined: Tue Sep 25, 2007 10:29 pm
Location: Bellevue, WA
Contact:

Postby Sirius » Tue Apr 29, 2008 8:32 pm

Yeah, light maps were pretty much used throughout Quake 1/2/3 and early Unreal games, as far as I can tell. I think some games might still use them in some capacity, but with the advent of pixel/fragment shaders they're not so required any more.

A level I just finished made it painfully obvious what quality issues per-vertex lightmaps can cause on a low mesh resolution... I should upgrade XL and try it again, might look a lot better...!

P.S. While I remember it, Descent 3 used lightmaps as well.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Postby karx11erx » Tue Apr 29, 2008 8:46 pm

I think that light maps are still used for all static lighting - at least unless deferred shading (with its own problems) is employed. Believe me: Even with rather low quality light maps, static lighting in D2X-XL looks very good - tangibly better than per vertex lighting (even for fine meshes).

As I wrote: Light maps have the same effect as per pixel shading, but w/o the run time cost. And per pixel lighting costs dearly in a game like Descent with its often excessive amount of light sources. You either have to render only the brightest, closest ones or resort to multi pass rendering, which slows the renderer down and poses the problem of undesired and hard to control light saturation.
Last edited by karx11erx on Tue Apr 29, 2008 11:26 pm, edited 2 times in total.

Return to “General Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest