Refraction/Real Water

#1 Alexander,

Doing effects like these is not the problem, I've written loads of little apps that do all sorts of fantastic stuff with the hardware and it's great fun.

The problem comes when you want to gain access to the support within Torque. If you follow the existing architecture then you've got to maintain the following...

- OpenGL Support (Have to implement support for each chipset as access comes in the form of manufacturer-specific extensions).
- DirectX Support (Alot easier as there is a high-level shading language on it's way but is limited to the Windows platform).
- Multi-platform support (This means that you would definately have to implement the OpenGL support above as DirectX is for Windows only)

I'm not saying it's impossible, it's just alot more work than it first appears and you have to be sure of what your target systems are first. Even if you stick to the Windows platform then you will find that to give yourself a big a user-base as possible you really need to implement OpenGL/DirectX. Initially you would get the most users from doing it in DirectX.

- Melv.

#2 @Melv : i understand your point. Note that there are already some features in Torque that are enable only if your video card accept it (NPatch for Radeon).

Concerning the different remarks you made, is it more related to shader support (different opengl extension per card manufacturer), or to something else. Do you think it's reasonable to have software support for unsupported features (indeed, there is a voodoo driver in torque).

I'm 'refactoring' torque code (mainly to add dynamic lib support, app embedding support and new features). Then, I'm also asking myself all these questions and some answers are difficult.

#3 What about Opengl 1.4?

Will that GL_ARB_vertex thingymajig bring support for vertex shaders (thus allowing these effects to be universally possible) among opengl cards?

#4 Frank,

My own personal feelings on introducing advanced features is that we need a unified approach. Adding NPatch support to gain a certain advantage with meshes is one thing but adding shader support for each card manufacturer is another that potentially affects all stages from DCC right upto in-game rendering.

What I was driving at is that there is a huge interest from people on the forums to see 'shader' support. Not only because it's a powerful way to access graphics hardware but also because it's the latest buzz. There seems to be a feeling floating around that it's not been put in because no-one has the time and that it's badly needed.

I strongly disagree with this. As you know, there is a bit of a revolution going on now with graphics technology where we are finally able to utilise what has been around for quite a while, a programmable gpu, and a move away from an outdated fixed-pipeline api desperately trying to catch-up with the underlying hardware.

I think we would be wise to take stock and hold fire for a little while longer before we commit to any one method. If we don't I see the Torque becoming a hybrid monster that we'll have to restructure further down the line when gpu access becomes more unified.

I believe a unification of this kind is going to happen much sooner than we think. Moores law dictated that data density (or advancement) would double every 18 months. The graphics industry is currently running around 4-6 months with software lagging way behind.

Although there are games utilising shaders, what games really use the available hardware to it's limits like we had over the last decade? I think adding a little bump-mapping here and a little phong shading there doesn't do any harm but I am reluctant to jump in without wheying the options.

Now to my real point. All of the above doesn't apply if you have already got a target audience. If you want windows PC's then just implement the HLSL when DirectX9 comes out. If you want Linux/Mac users then that means OpenGL. If you're doing OpenGL then you've got to decide whether you force OpenGL on your PC users and if not then you've got to do DirectX support as well.

Other alternatives are coming out and hopefully in six-months we will be spoilt for choice. Take Cg from nVidia or RenderMonkey from ATI, these are potentially amazing tools but they are still in their infancy.

A focused attack on a specific area is great but to appeal to the *whole* community will take a serious investment of time and energy and should not be taken lightly.

*I bet you wished you never asked now* ;)

- Melv.

#5 Stuart,

Yes, assuming card support for this extension then this is the beginnings of a unified api. Unfortunately, this doesn't cover pixel fragments.

OpenGL 2 is the next best thing and is certainly trying to be future proof with abilities that should enable it to take advantage of .1 micron technologies. We are still moving from .15 to .13 (nVidias NV30).

The future looks bright, the future seems to be nVidia/ATI (with Matrox licking it's wounds).

- Melv.

#6 I take a slightly different line than Melv on this point.

I think shader support *IS* worthwhile NOW. However, I do think it requires a concentrated effort to cover the whole of the engine in enough detail that the engine benefits substancially from the changes (i.e. just hacking in shaders for a specific thing isnt worthwhile).

The reason why I think shader implementation is worthwhile now is that if we look at how the renderer works, its CLEARLY got a lot of inefficiencies, for instance not using buffers enough, having seperate render methods for objects, not enough batching etc.

Adding "fundamental" shader support is simply changing the focus from individual render objects in a heirarchy (old school) into proper batching and state management (the new school approach).

Although shaders implies hardware shaders, I'm of a mind that a proper shader implementation includes a higher level interface which could hide most of the implementation issues while still giving the structural and organisational benefits that shader based systems allow (i.e. artistic support, dynamic scaling, fast turnaround etc.

I think moving to a nominal software shader pipeline NOW (i.e. does what it does now, but in a shader friendly way) would still give us performance benefits, which then paves the way for more detailed implementation later on.

Phil.

#7 Phil,

Yes, I would agree with that approach. It's very difficult to get across your point in text. There are many aspects to it that each have their own merit and timescales. Creating a software shader pipeline or at least organising the existing areas of Torque into a unified pipeline is a worthy investment and can and should be done now.

I was just trying to get across the point that it's not essential that we jump head first into one approach and that holding back a little is far more important than bashing something together. I'm not saying anyone is doing that, It's just not how I personal would like the Torque to go. Really just emphasising your quote of "just hacking in shaders for a specific thing isnt worthwhile".

I don't want to put dampners on something that is revolutionary and very exciting, I just think it should be done right first time. With such a community resting on the codebase, adding stuff is always appreciated but removing stuff in place of another, completely different system whilst trying to maintain the existing one is very difficult not only for the programmers but for the users e.g. modellers etc.

I don't want to look like I don't want this now, I do, I'm just trying to tell a cautionary tale. ;)

- Melv.

#8 On the refraction:
It would be very nice to see it ingame and have either particles doing it or models- i'd like to know if its possible. what i mean is having heat distortion or better cloaking effects. if you've seen nvidias chameleon walking video- u know what i mean. transparency w/ alpha chanels is one thing but meodels capable of refration is another. also you should check out the bubble demo on the site its a great example. i'm wondering if someone can put in an extra field for the color system:
R, G, B, Alpha, Refraction.

I've noticed in some games that there are two different data sets- high and low. perhaps those with geforce4 or similar card could use high. Maybe we could have a whole game for refraction and all that and one for simpler stuff
maybe either connect them for MP or just use the special effects for SP

#9 Alexander,

If I remember the chameleon demo correctly, the effect you see was *simulating* refraction/reflection. What was actually happening was that pixel shaders were being used to lookup per-pixel fragment offsets into a cube-map. Just reflection/refraction fragment operations blended together.

It looked sweet but wasn't reflection/refraction.

Now the new ATI 9700 demos, they are really sweet. That reminds me, next Tuesday/Wednesday for my 9700 ... can't wait. ;)

- Melv.

#10 but i take it that it would be possible to do an ingame refraction effect tho. more games now are taking more hd space and higher reqs. why not compete?
I would try and do it, yet i'm not as good with the engine and i sure as hell don't know the mathematics involved.
also- melv i was wondering, if your looking for a challenge- i dont know if its possible but maybe you can try and modify the foliageReplicator system to do clouds or sections of fog, rether that whole planes of fog?

#11 I'm not the foremost authority on this topic, so don't take my words as necessarily correct.

OpenGL is not close enough to offering unified coverage of programmable shaders. They have DX8 level vertex shaders standardized and that's about it. DX8 level pixel shaders are due out in GL 1.5, I believe. Meanwhile, 3Dlabs and nVidia are trying to get their implementations of HLSL as the official shader language of GL. In my opinion, nVidia has the drop on 3Dlabs simply due to having their product out in beta form while no one is using 3Dlab's version.

Well, at least we have the hardware guys realizing that us software guys need a more centralized, powerful way to address programmable hardware than card-dependent assembly code.

The contestants for out solution are DX9, Cg and OpenGL 2.0. As Melv said, DX9 is kind of out of the question simply due to incompatibility with Linux and Mac, not to mention the problems inherent in getting DX9 shaders running on a GL base.

As far as I know, RenderMonkey from ATi is really just a good shader manager/previewer. I'm not aware that it is a language unto itself.

The only real contestants as far as we're concerned are Cg and OpenGL 2. Both should be as compatible as we need them to be, and they should cover more programmability than the current GL_ARB extensions. Our decision seems more in the hands of the ARB than anyone else. Neither contestant is being used yet, so latching onto one now might prove detrimental.

Personally, I favor Cg, but that's just me. I've already messed around with it, and it should have a good manager/previewer program associated with it when Cg hits release.

I have not looked around the rendering code of Torque much yet. If Phil is right, as I assume he is, getting Torque prepared for programmable shading is *exactly* what should be going on now. It won't be too long before such power is mainstream, and if we don't prepare for it now, Torque will look outdated with little hope of returning to the cutting edge.

Actually, how GarageGames plans on keeping Torque cutting edge over a period of several years would be good to know.

#12 @Melv & Phil: I agree with both of your opinions. Your comments are very valuable. Concerning the shaders topic, i really think like Phil that we should end up with a higher level interface that hide all the system specific code (shader interface). I tend to like how CG is going with NVidia releasing sources of its compiler, however i do not know if ATI will go into that way. My point was mainly that if we need to put new features in torque (shaders, plugins, ...), i really think that we should change some part of torque architecture otherwise we may end up with something quite difficult to work with.

#13 A working "plug-in features system" would be very nice. With new versions AND new resources, working with Torque could be hell.