Ati's gpus for the last few generations have supported hardware tesellation, and it is now part of the DirectX 11 specification, so Nvidia will have to step up too.
Although Spring does not use DX11, it should still have access to this hardware as it becomes more common via OGL, yes?
Is there any interest among the developers in adding hardware tesellation to the engine, two obvious examples being for organic units and terrain rending enhancement?
Hardware tesellation?
Moderator: Moderators
Re: Hardware tesellation?
For organic units you really need a better model format with actual skinning (I mean bone weights per vertex). Would hardware tesselation really add anything without that?
Re: Hardware tesellation?
Uh... <looks up "hardware tesselation">
So, basically, it's a really fast, automated LOD method, using patches instead of triangle data as the basis. In theory, you can have extreme levels of detail, reduced in complexity by a shader to produce your final triangles.
It's DirectX 11 only atm, and very little available hardware actually supports it. OpenGL 3.0 barely supports the features of DirectX 10, and we all know how many problems there have been with various hardware and OpenGL standards around here.
It's pretty obvious, just reading through the articles, that there is a major standards war going on about this and other things.
Basically, it's neato, but completely unsuitable for Spring atm, imo.
As for organics... meh... we just need an appropriate model format, or at the very least, methods using S3O vertex data in novel ways.
So, basically, it's a really fast, automated LOD method, using patches instead of triangle data as the basis. In theory, you can have extreme levels of detail, reduced in complexity by a shader to produce your final triangles.
It's DirectX 11 only atm, and very little available hardware actually supports it. OpenGL 3.0 barely supports the features of DirectX 10, and we all know how many problems there have been with various hardware and OpenGL standards around here.
It's pretty obvious, just reading through the articles, that there is a major standards war going on about this and other things.
Basically, it's neato, but completely unsuitable for Spring atm, imo.
As for organics... meh... we just need an appropriate model format, or at the very least, methods using S3O vertex data in novel ways.
Re: Hardware tesellation?
Ooooh i remember something called ATI Truform
...from the times of DirectX 7 and HW T&L?
Wiki lists OpenGL games as supported (like Quake and RTCW) so i dont know where you are getting the 'DX11 only' from
Stop the OpenGL bashing it makes my inner penguin cry ;____;
...from the times of DirectX 7 and HW T&L?
Wiki lists OpenGL games as supported (like Quake and RTCW) so i dont know where you are getting the 'DX11 only' from
Stop the OpenGL bashing it makes my inner penguin cry ;____;
Re: Hardware tesellation?
Just reading the stuff they have to say, frankly. TBH, it mainly sounded like a very bad idea that will be surrounded by much fanfare. I'm more interested in seeing what happens if Carmack ever completes his baby, 'specially since BethSoft will undoubtedly be sitting on any patent that arises.
Re: Hardware tesellation?
Andrej wrote:Ooooh i remember something called ATI Truform
...from the times of DirectX 7 and HW T&L?
Wiki lists OpenGL games as supported (like Quake and RTCW) so i dont know where you are getting the 'DX11 only' from
Stop the OpenGL bashing it makes my inner penguin cry ;____;
+1 ^^
Re: Hardware tesellation?
JC has it right.jcnossen wrote:For organic units you really need a better model format with actual skinning (I mean bone weights per vertex). Would hardware tesselation really add anything without that?
Re: Hardware tesellation?
If it's unsuitable for Spring, A-OK but I'd like to clear up what seems to be a misconception.
I don't think there's really a "standards war" going on - Microsoft is doing what open-source can't: they've got stones big enough to just say "hey guys, so we've got this thing coming out, DirectX11. This is the way you'll program it, or you can just all go to hell. Ok? Thanks."
Truform was never anything more than a tech demo (exaggeration) but it has given ATI a lot of expertise in that area. They are quick to point out that they're producing their sixth generation of hardware tesselation right now.
DX11 is going to be coming out later this month, along with every PC vendor releasing an assload of Windows 7 PCs equipped to handle DirectX 11. Every high-performance PC will be equipped with ATI - that much is almost a certainty, since the 58xx series is busy right now sodomizing everything NV's ever done.
By year's end NV is expected to have their own DX11 card, and hardware tesellation support - whether emulated (as seems to be the case from recent NV rumors) or actual hardware (ATI) - is a mandatory part of the specification. Either NV will support it or they'll be DirectX 10 compatible and not sell a single card.
So it's an emerging technology still, but I think it is worth investigating if any developers feel up to it. It would seem, in theory, to be an ideal addition to map rendering at the very least, and if anyone start actually making high-poly units - even mechanical ones - it would be an asset there too.
It's only a matter of time before OGL supports it, from what I've seen lately they just copy whatever DX does anyway. Isn't OGL4 coming out in the near future?
I don't think there's really a "standards war" going on - Microsoft is doing what open-source can't: they've got stones big enough to just say "hey guys, so we've got this thing coming out, DirectX11. This is the way you'll program it, or you can just all go to hell. Ok? Thanks."
Truform was never anything more than a tech demo (exaggeration) but it has given ATI a lot of expertise in that area. They are quick to point out that they're producing their sixth generation of hardware tesselation right now.
DX11 is going to be coming out later this month, along with every PC vendor releasing an assload of Windows 7 PCs equipped to handle DirectX 11. Every high-performance PC will be equipped with ATI - that much is almost a certainty, since the 58xx series is busy right now sodomizing everything NV's ever done.
By year's end NV is expected to have their own DX11 card, and hardware tesellation support - whether emulated (as seems to be the case from recent NV rumors) or actual hardware (ATI) - is a mandatory part of the specification. Either NV will support it or they'll be DirectX 10 compatible and not sell a single card.
So it's an emerging technology still, but I think it is worth investigating if any developers feel up to it. It would seem, in theory, to be an ideal addition to map rendering at the very least, and if anyone start actually making high-poly units - even mechanical ones - it would be an asset there too.
It's only a matter of time before OGL supports it, from what I've seen lately they just copy whatever DX does anyway. Isn't OGL4 coming out in the near future?
Re: Hardware tesellation?
Again an ATi fanboy read papers for devs.
Don't talk about stuff you don't understand!
Don't talk about stuff you don't understand!
Re: Hardware tesellation?
The OpenGL standards committee, is not an opensource entity, it doesn't have any code at all to its name, and there are many commercial closed source entities involved too.
OpenGL is an industry standard not a linux standard
OpenGL is an industry standard not a linux standard
-
Master-Athmos
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: Hardware tesellation?
They just have lots of manpower and have created the most modern API. Since DX9 OpenGL started to fall behind a bit in terms of supporting the latest GPU inventions rendering it next to unimportant for the gaming sector which is what DX is all about (while OpenGL isn't meant just for that)...Caydr wrote:Microsoft is doing what open-source can't: they've got stones big enough to just say "hey guys, so we've got this thing coming out, DirectX11. This is the way you'll program it, or you can just all go to hell. Ok? Thanks."
Yeah - I don't really know why Truform got ignored to that extent (it was in games like Counter Strike though). NVIDIA also had something like Truform though - it at least was developed. Unlike Trufrom it didn't "auto-smooth" things but the graphics artist had to define how to smooth at which points. That way it was more efficent than Truform but no one wanted to do all the work for something that much vendor specific and so it afaik never made it beyond a tech demo...Caydr wrote:Truform was never anything more than a tech demo (exaggeration) but it has given ATI a lot of expertise in that area. They are quick to point out that they're producing their sixth generation of hardware tesselation right now.
The tesselation technology itself is extremely interesting as it's going to increase the polycount with just a minimum of GPU power needed for that. I don't know why you think it would be a good idea right now for Spring. Polycounts really are the smallest concern you should have about models in Spring. Plus when not talking about the model format (and it's abilities) you probably should ask for instancing first (should be in OpenGL nowadays but I didn't track it) which like tesselation is another "minor goodie" but could considerably speed up some things / make new things possible at a decent performance...
Re: Hardware tesellation?
Hey, an expert like Argh hadn't even heard of it. A troll.jK wrote:Again an ATi fanboy read papers for devs.
Don't talk about stuff you don't understand!
Just trying to raise awareness of a new technology, and I admit I'd forgotten that OGL's obsolescence in the face of modern technology made it kind of moot.
Re: Hardware tesellation?
I treat this threads as what it is: a troll thread.
With the topics:
* ATi is uber
* DirectX rules
* OpenGL sucks
* Spring sucks 'cos it uses OpenGL
Sorry, such papers/topics need a lot of background information you don't have and neither Argh has.
With the topics:
* ATi is uber
* DirectX rules
* OpenGL sucks
* Spring sucks 'cos it uses OpenGL
Sorry, such papers/topics need a lot of background information you don't have and neither Argh has.
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Hardware tesellation?
No one said that, nor was it implied... O_ojK wrote: * OpenGL sucks
* Spring sucks 'cos it uses OpenGL
Re: Hardware tesellation?
Not in this thread. Caydr talked about that in the ATI thread in a trollin' mood.
Also, note that jK has an excellent point - you need context to understand the material. That is partially a problem of the nature of specialization - unnecessarily narrow paradigms of thought, a particular vocabulary, information kept out of the mainstream... but all that aside, you really need the background.
Also, note that jK has an excellent point - you need context to understand the material. That is partially a problem of the nature of specialization - unnecessarily narrow paradigms of thought, a particular vocabulary, information kept out of the mainstream... but all that aside, you really need the background.
Re: Hardware tesellation?
I didn't say OpenGL sucked, nor am I an ATi fanboi. If anything, I'm an nVidia fanboi.
And I certainly didn't claim to understand it past the basic gist. I've used patch-and-spline modelers a lot (Rhino uses them, I used to work with Pixels3D, so this isn't exactly new territory for me) so I'm familiar with the concept of tessellation according to need. But frankly, that's pretty much my full knowledge of this, other than my limited exploration of writing shaders in different application contexts.
I think that Carmack's approach sounds more credible for serious speed down the road, though, within the relatively tight confines of gaming graphics. That, and Carmack's record is really good, so I tend to believe him, when he says that he's working on something that will be groundbreaking. I also don't think BethSoft would have bought id, if they weren't also pretty convinced that there's something there.
As for whether there's a standards war going on... don't make me laugh. You don't even need to read between the lines, people. You just need to read more than one article and leap to conclusions.
There are at least 4 major teams and at least a dozen university groups that I've read references of, with a huge amount of money and resources, working on different solutions for the next generation of graphics tech.
There is a lot of controversy, too, which usually indicates that something really big is happening. There's this huge scuffling match between people who say that the GPU is finally a dead idea, and people who think that that is still very premature, and they're all wanting to see some pretty big changes in overall architecture, no matter who wins.
I think it's fair to predict that DirectX 11 represents an incremental step forwards, not a radical change in posture, and may become irrelevant before it's even mature, but that really depends on not only who gets there first, but whether they're able to swing the hardware people. It may turn out, for example, that Carmack's approach really does work better, but doesn't arrive for another decade, simply because it takes that long for the hardware people to change directions.
Now, how much of this matters, in the context of Spring?
None of it. Spring is largely an OpenGL 1.x spec piece of software, with some limited use of OpenGL 2.x spec functionality, and access to the latest-greatest 3.x spec stuff (some of it, anyhow), but only if you are an actual expert and can hack the Lua and GLSL necessary- the engine's support for non do-it-yourselfers is zero, zip, nada, nor is there much serious work being done by the engine-side people atm on going to the next level, so don't hold your breath.
For Spring to merely take advantage of OpenGL 2.x features throughout its rendering system, it would require a lot of serious changes to how it works, and I really don't see that happening, other than end-runs around its limitations via Lua. This is where things stand atm, and will probably continue to stand, as there doesn't seem to be the willpower or skill to do otherwise with such a mature system. That may change, if somebody develops the sourcecode to drive Spring's rendering in better ways, but until that happens, we're stuck with what we have, plus a number of options using Lua that greatly extend it... if you have the skills to plug it in and use it.
And I certainly didn't claim to understand it past the basic gist. I've used patch-and-spline modelers a lot (Rhino uses them, I used to work with Pixels3D, so this isn't exactly new territory for me) so I'm familiar with the concept of tessellation according to need. But frankly, that's pretty much my full knowledge of this, other than my limited exploration of writing shaders in different application contexts.
I think that Carmack's approach sounds more credible for serious speed down the road, though, within the relatively tight confines of gaming graphics. That, and Carmack's record is really good, so I tend to believe him, when he says that he's working on something that will be groundbreaking. I also don't think BethSoft would have bought id, if they weren't also pretty convinced that there's something there.
As for whether there's a standards war going on... don't make me laugh. You don't even need to read between the lines, people. You just need to read more than one article and leap to conclusions.
There are at least 4 major teams and at least a dozen university groups that I've read references of, with a huge amount of money and resources, working on different solutions for the next generation of graphics tech.
There is a lot of controversy, too, which usually indicates that something really big is happening. There's this huge scuffling match between people who say that the GPU is finally a dead idea, and people who think that that is still very premature, and they're all wanting to see some pretty big changes in overall architecture, no matter who wins.
I think it's fair to predict that DirectX 11 represents an incremental step forwards, not a radical change in posture, and may become irrelevant before it's even mature, but that really depends on not only who gets there first, but whether they're able to swing the hardware people. It may turn out, for example, that Carmack's approach really does work better, but doesn't arrive for another decade, simply because it takes that long for the hardware people to change directions.
Now, how much of this matters, in the context of Spring?
None of it. Spring is largely an OpenGL 1.x spec piece of software, with some limited use of OpenGL 2.x spec functionality, and access to the latest-greatest 3.x spec stuff (some of it, anyhow), but only if you are an actual expert and can hack the Lua and GLSL necessary- the engine's support for non do-it-yourselfers is zero, zip, nada, nor is there much serious work being done by the engine-side people atm on going to the next level, so don't hold your breath.
For Spring to merely take advantage of OpenGL 2.x features throughout its rendering system, it would require a lot of serious changes to how it works, and I really don't see that happening, other than end-runs around its limitations via Lua. This is where things stand atm, and will probably continue to stand, as there doesn't seem to be the willpower or skill to do otherwise with such a mature system. That may change, if somebody develops the sourcecode to drive Spring's rendering in better ways, but until that happens, we're stuck with what we have, plus a number of options using Lua that greatly extend it... if you have the skills to plug it in and use it.