How to do 3D graphics development on the Amiga?

[Rogue]

Actually, theres actually nothing stopping antialiasing being used on existing v4.2 warp3d other than the fact that none of the currently supported chipsets seem to have it. Actually, I coudln't say for later voodoo chips

This is correct, although the latest Voodoo (VSA-100) does support FSAA. Theoretically it could be turned on, just use W3D_SetState(context, W3D_ANTI_FULLSCREEN), but no driver up to now supports it; there is no official support for Voodoo 5, although I have one in my classic and it works without problems.

Hmmm. According to sect 2.1 of the permedia2 programmers reference manual, it has 'full scene antialiasing', but I'm buggered if I can find it elsewhere in the documentation.

I seem to remember that Sam had this discussion with someone Permedia 2 guy that claimed there was anti-aliasing, but it more or less turned out that there was a windows driver for the card that simulated that. Needless to say the fill rate of the Permedia 2 is low enough to make such tricks work only on triangle-limited scenes...

[Rogue]

Yeah, that closed source, in-house developemnt only, non-standard low-level library, successor to Warp3D, wich suffered the same limitations.

The same applies to Direct3D. OpenGL is all nice but the ARB has a way of being a bit slow when it comes to making decisions.

Besides NOVA won't be so low-level anymore (including a full 3D pipeline, shader language etc).

The other problem with a general-purpose OpenGL implementation is that some things are not really working, or require a myriad of different code paths to achieve. A recent project we're doing on Linux requires access to the depth buffer. You can of course use a pixel transfer function, but these happen to be extremely slow on some cards, meaning you will need to have all the cards to test and invent other methods for others. With Warp3D we don't have this problem.

Also, the "as little as needed to run Quake" attitude, wich is perfectly ok from Hyperion point of view (MiniGL suit their needs), is not going to make that API broadly accepted for general purpose 3D use.

That goes for MiniGL. Warp3D is as limited or complete as e.g. Glide, and was never intended to be more than that. General OpenGL is/was too slow for the classics; MiniGL made Quake 2 playable on the 060.

The reason for this "articifical limitation" in MiniGL was simple - there was a goal that I wanted to achieve, and that was a fast, thin OpenGL-lookalike API on top of Warp3D that was sufficient for our ports. We never intended to do anything else. StormMesa was for anyone that did want more than that.

We're just too busy on fighting on the speed of AGP busses (as if it could make ANY pratical difference) to see where the competition is going... light years ahead.

Quite right. A Mesa port all in itself will not be the answer to that, though - you'd have to write those hardware drivers too (unless you want to port DRI too). However, you will still see a big performance gap between Windows and Linux.

We have a plan for the future, which I am not going to get into here, that we hope is going to amend this situation. Until that time any solution is going to be an interim one, but that is the best you can do at the moment. This interim solution will consist of Warp3D and Mesa at the moment, and may be NOVA, Mesa or something else (in one or the other combination) in the longer run.

[Rogue]

That is what I'm talking about. If Amiga wants to live in the past, by all means ignore advanced 3d hardware.

I would love an Amiga comeback, but for the general market, it will never happen without full, unapolagetic support for 3d.

Sorry to say so, but this is not about "wanting to live in the past". Currently it is being enforced.  You need to go with what you can get, and that generally excludes anything of NVidia's offering for example.

[Rogue]

i had expected someonmne from hyperion to join in this discussion but they havent....sort of weird

You know, there's this big project that we're working on that is taking quite some time ;-)

[Rogue]

As you mentioned all the different code paths required on OGL becomes a nightmare, in DX its easier, the effects stuff in DX are quite interesting, even though I've not personally used them.

Yeah, the different code paths are my biggest gripe with OpenGL. You practically must have all the hardware (or testers available) in order to make use of them. Just compare the different fragment shaders (most OpenGL drivers support ARB_vertex_program now).

Plus, some of these extensions are burdened with copyrights. I think that e.g. NV_vertex_program is copyrighted by nvidia and may only be implemented on NVidia hardware (although Mesa has a special, software-only permission).

I never used the Effects stuff in DX either, but the SDK samples look quite promising. I wonder if anyone is using the D3DX model code - doesn't look that bad either.

[Rogue]

However if you are developing multi-platform stuff you are most likely going to "roll your own" model format, which can be quite flexable with DX and cards supporting multiple streams.

Sure, the non-portability is a problem, but then it didn't stop you from using D3D in the first place :-) I mean, not many people in the windows world really care about portability (otherwise there would always be some sort of file I/O abstraction that is endian aware... *Sigh*)...

[Rogue]

Does snap be able to comunicate with WARP3D ?

Obviously, there needs to be a link between a 2D and a 3D driver. Command transport arbitration is one thing, and resource management (like textures etc) is another.

Will snap gives to AOS4 the possibility to use 3D functionalities of all the cards supported ? something like 200 cards !!!

SNAP drivers, at the moment, only provide 2D functionality.

[Rogue]

I have never tried StormMESA in any way shape or form

Since OpenGL doesn't define a Windowing interface, and everyone rolls their own (Apple's AGL, Windows' WGL and X11's glX) it is likely that this is a reason why it fails to interoperate..

Just a guess, though.

[Rogue]

In any case, I could care less if Amiga had a DirectX or an OpenGL, or something new.

Agreed. Ideally portability of the API isn't so much of an issue since most of the concepts are the same. As soon as shading languages come into the picture, things get nasty unless you use Cg, or roll your own.

What I care about is that there is some equivelent that lets me write shaders, preferably in a HLSL/Cg/Slang-eque language, which can compile down to the actual Vertex and Fragment program specs, and which otherwise take advantage of all the hardware features found in today's cards.

Like I said, NOVA is meant to be shader centric with the "normal" fixed-function pipeline being a special case.

I don't understand the lack of a concrete vision and story for 3D on the Amiga. Saying that such and such API is possibly coming out, and not knowing what it actually is capable of and how it works, is not what I'm talking about.

Oh, the question is different. It is either OpenGL 2.0, or NOVA, or both. If we go for NOVA, we already have a very clear idea about how it will look. However, the problem is lack of documentation. If we can get a good OpenGL 2.0 support we might drop the idea of rolling our own API, but if we had to write it all ourselves anyway, we'd implement the NOVA proposal (which already exists, internally).

*If* Nova comes out, we know quite well what it is going to be capable of. However, there are too many unknowns to consider (time not the least) therefore anything else is speculative, and saying this or that could be misleading.

At this point I would be happy with a gaurantee that such a featured API is coming out

There will be such an API. It's either going to be OpenGL or NOVA; but it *will* be one of the two, preferrably both.

[Rogue]

a very nice feature for future API/OS would be for each application to render to a texture

Yes, that is a very interesting aspect. On OpenGL you need something like the p-Buffer extension to actually do that, which is a bit problematic (what are you going to do if that extension is missing). Here's my major problem with OpenGL - what if that extension is missing...

As for 3D, it would be nice to have along side vertex and pixel shaders, geometry shaders. So logical operations can be performed on "geometry" (And or Xor etc).

I'm not aware of any modern graphics card that can actually do that. They operate on isolated vertices, or fragments, but not on geometry. There is no connectivity information passsing through the shaders.