Announcement

Collapse
No announcement yet.

Unigine Heaven On Linux In A Month Or Two

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    dragengine?

    Comment


    • #32
      Originally posted by smitty3268 View Post
      The older gpu tesselation support isn't nearly as powerful or flexible, it's essentially what ATI developed for the XBox360 GPU. It was never used on PCs because NVidia didn't have anything comparable and developers apparently decided it wasn't worth using if only half their customers would benefit.
      It goes beyond that too. Before DX11 was defined, tesselation was a neat idea, but remained an extension that was ATI specific.

      Now that it is included in DX11, suddenly it is a lot more important - it will allow PC gaming jump up in visual fidelity quite a large amount (without causing large costs in non-GPU model complexity. All mesh changes and transforms are done on the simpler model (6k triangles for the dragon in heaven), but are then bumped up to the millions of triangles on the GPU for render.

      I am not sure if the OpenGL tesselation extension will reach back into older GPUs, but there may be HW specifics that either the extension needs, or that Unigine relies on.

      Regards,

      Matthew
      Last edited by mtippett; 10-23-2009, 03:26 PM.

      Comment


      • #33
        Originally posted by RealNC View Post
        "Unified shaders" were introduced with promise that they can be programmed to do generic work. Now they tell us they actually can't and to get new hardware instead.

        It's always like that. First make promises, then break them.
        Maybe if, instead of whining on internet forums, you'd actually educate yourself slightly about graphics hardware, you wouldn't end up so disappointed. You're making up stories based on what can only be described as peripheral knowledge and hearsay, and then holding it against IHVs when things don't turn out the way you fooled yourself into believing they would.

        Comment


        • #34
          Unfortunately he's right. That tessellation stuff is another "holy-grail" of the graphics industries which doesn't hold up to what it promises. Not the first time this holy-grail syndrome happened and for sure not the last time. I would definitely prefer a game/engine doing proper lighting and what else to one which wastes hardware on something like tessellation which has a good deal of problems attached to it. It's anyways a bit questionable to waste hardware on tessellation but on the other hand you have no shadows at all for anything else but the sun-light. If something is not tessellated ( even assuming you fail at doing normal mapping properly ) it's less of a visual problem than missing shadows or other interesting gadgets. And locking yourself in with DX11 for that is another questionable move.

          That said though it's their decision. Not much for me to question in the end so I guess I'll go back to the non-speak zone ( and anyways didn't wanted to post but sometimes you just can't sit on your mouth any longer :P )

          Comment


          • #35
            Originally posted by Dragonlord View Post
            Unfortunately he's right. That tessellation stuff is another "holy-grail" of the graphics industries which doesn't hold up to what it promises. Not the first time this holy-grail syndrome happened and for sure not the last time. I would definitely prefer a game/engine doing proper lighting and what else to one which wastes hardware on something like tessellation which has a good deal of problems attached to it. It's anyways a bit questionable to waste hardware on tessellation but on the other hand you have no shadows at all for anything else but the sun-light. If something is not tessellated ( even assuming you fail at doing normal mapping properly ) it's less of a visual problem than missing shadows or other interesting gadgets. And locking yourself in with DX11 for that is another questionable move.
            There are some nice benefits of tesselation.
            1. You deal with a simpler model in your engine. Collision, transforms, movement, etc are all done on a simple < 10k model.
            2. You need to carry in a lot of cases less content on the host side, particularly with procedural tesselation
            3. You push *way* less geometry around. The GPU renders millions of triangles, your engine pushes 100's.
            4. If you have shadows (like Unigine does), your shader based light model can interact with the actual tesselated geometry.

            If you look at the shadows from the dragon with tesselation, the bumps and so on are also included in the shadows. If you don't use tesselation, you'll just get the simple shadow.

            Obviously if you do host side pre-rendering, you don't get the tesselated geometry, which may be result in issues that you highlighted. But I believe that Unigine's light model is almost entirely shader based.

            Comment


            • #36
              Originally posted by MaestroMaus View Post
              Boohoo, there are people out there who like deathmatch and there are a lot of linux games out there with deathmatch...

              Sorry guys but your getting repetitive and cheap. I understand it must be frustrating that there aren't many games of your favorite genre on Linux but stop beating the dead horse please. We have heard the complaint over and over now here on Phoronix and we are aware of it. Be happy for the deathmatch lovers for a change.
              We need another run and gun fps title on linux like we need another hole in our heads, I dunno about you but aside from a match or 2 every few weeks in QL is way more then enough FPS. I'm bored to death with quake remakes on linux and nobody is even making an attempt at making a single player fps game like the S.T.A.L.K.E.R. series that I got around to playing only becaue I borrowed a friends windows box for a few days.

              If linux gaming is going to be taken seriously it needs to break out from the "id just released the idTechover9000! engine, lets make yet another uncreative, repetitive Quake or UT clone that almost nobody will play regardless that it's free or not because by the time we have a working title everybody and their cat has a copy of UT 2k25 that they picked up for $2 at Crazy Sal's Bargain Hut."

              If you're going to make yet another fps you could at least make an attempt at not doing the same as every other linux fps, the same game just with different models and varying levels of graphics polish.

              Don't give that crap line about "nobody will give art for free" theres tons out there, google around, whatever else you need start bumming around forI'm sure theres a few students out there.

              Comment


              • #37
                Originally posted by Dragonlord View Post
                That tessellation stuff is another "holy-grail" of the graphics industries which doesn't hold up to what it promises.
                The only people calling it a holy grail are marketing folks and people who don't know what they're talking about. This will eventually lead to people whining that it was in fact not the holy grail they thought it was, which was my point above. It's the same every goddamn hardware generation, be it GPUs or consoles, and it's starting to get real old.

                For developers tessellation is just another tool for the toolbox. Something they can use to do some cool stuff. Nothing more, nothing less.

                Comment


                • #38
                  Originally posted by mtippett View Post
                  NVidia looks like the untesselated version, I believe they want to wait until the demo can be viewed "as intended" - with tesselation.
                  Do I detect a litle *poke* *poke* *nudge* *nudge* ?

                  Comment


                  • #39
                    Well ATI seems to shine now until Nvidia has got DX11 chips... But the driver does not seem to be good enough for the demo, oh who did expect that Even John Carmack sees problems with fglrx and he is much more important than Unigine...

                    Comment


                    • #40
                      Originally posted by Duo Maxwell View Post
                      Don't give that crap line about "nobody will give art for free" theres tons out there, google around, whatever else you need start bumming around forI'm sure theres a few students out there.
                      I dont know if its my scene or just that people dont look... but i know plenty of talented artists that only want acknowledgement for the work they do. Im not talking about moddb talent either . This can best be described as pretending to be on a team for 2 weeks and then disappearing.

                      Artists just want to be loved. It should be no surprise that they dont like FOSS projects based on IDtech X because no one plays then. They are old, lack creativity, and are all generally the same. No one wants to do art for a game that no one is going to play....

                      Nexuiz and alien arena, bend that bar a little bit. But at the end of the day its mostly the same stuff. Take open arena: We can all agree that it is ugly as hell. I have offered my services to the team previously; but they seem content on having dirty ass maps with 2 walls, a floor and little else. When a dev team does this, the blame is placed on them, not the world of artwork.

                      I will be the first to know that programmers will build a game around what they want, and we have to live with that. If we want to mix it up a bit then we need to get creative. Until then its deathmatch on linux.

                      And may the double damage be with you.

                      Comment


                      • #41
                        I tried making a 3d animation once that used tesselation (specifically Kai Kostock's custom build of Blender) to show an ocean scene that went from right by the camera to hundreds of km's away. It worked well, with one major problem. You would see the "pops" between frames where something went from lower to higher resolution (or the other way around).

                        Oh, for the record I'm actually no fan of death-match shooters (power to people who are). My first comment was morejust pointing out that I'd buy a game that looked like that even if they didn't actually add a huge amount (like a 100 page story covering 50 characters Final Fantasy style).

                        Any new game that looked that good on Linux would be a good thing. I'd love to see a platformer myself, but I'd still buy a FPS deathmatch shooter.

                        Comment


                        • #42
                          Originally posted by mtippett View Post
                          You deal with a simpler model in your engine. Collision, transforms, movement, etc are all done on a simple < 10k model.
                          You don't do this since ages anyways. You don't interact with a full mesh in a physics simulation anyways since triangle meshes are bad for physics. Also for movement you don't work with meshes themselves you work with analytic bodies. So point denied.
                          You need to carry in a lot of cases less content on the host side, particularly with procedural tesselation
                          To support tessellation you need to bring in extra geometry information. You just go from one type of added information to another. No real gain in all this.
                          You push *way* less geometry around. The GPU renders millions of triangles, your engine pushes 100's.
                          For static geometry you push this data around exactly once. Wow, what a great gain. For dynamic content this applies but there we get into another set of big problems with tessellation.
                          If you have shadows (like Unigine does), your shader based light model can interact with the actual tesselated geometry.
                          It's called Deferred Rendering, known since a long time and works by separating geometry production from lighting. Lighting/Shading is already separate from geometry creation so point denied. Besides there exist already techniques to produce self shadowing. Another point is that shadow shaders are typically vertex bound. Increasing geometry burns your card without delivering much result.

                          There are situations where tessellation can be interesting but splattering it all across the screen is a waste especially if the rest is looking worse since the render time is missing for that.

                          Comment


                          • #43
                            Originally posted by Mr_Alien_Overlord View Post
                            It worked well, with one major problem. You would see the "pops" between frames where something went from lower to higher resolution (or the other way around).
                            That's why you don't switch from one tessellation level to the next immediately. The Heaven benchmark smoothly blends the levels together so you don't get popping.

                            Originally posted by Dragonlord View Post
                            To support tessellation you need to bring in extra geometry information. You just go from one type of added information to another. No real gain in all this.
                            Where in the pipeline you add the extra detail matters though. You already need a normal map in most games, and that's usually all you need in the way of extra information to tessellate. You also save a lot of bandwidth and vertex shader work by tessellating the geometry after the vertex shader. For skinning for instance this is a huge win since you only have to animate the low res mesh, regardless of actual detail level on screen. It does add hardware load, of course, but calling it "no real gain" is silly.

                            Originally posted by Dragonlord View Post
                            For static geometry you push this data around exactly once. Wow, what a great gain.
                            Nonsense. You pay for it every time you draw the geometry. It's cheaper to expand the data after the vertex shader stage than reading all that geometry from memory every time. ATI hardware is already generally bandwidth bound, so stuff like this helps.

                            Originally posted by Dragonlord View Post
                            It's called Deferred Rendering, known since a long time and works by separating geometry production from lighting. Lighting/Shading is already separate from geometry creation so point denied.
                            Parallax mapping, which you'll need to produce results similar to tessellation even in a deferred renderer, can't produce results nearly as good as properly tessellated geometry unless you go completely overboard with normal map samples. You'll have warping and heavy aliasing and it won't play nice with multi-sampling either. Tessellation is just better.

                            "Points denied". Am I doing it right?

                            Comment


                            • #44
                              Originally posted by wien View Post
                              Where in the pipeline you add the extra detail matters though. You already need a normal map in most games, and that's usually all you need in the way of extra information to tessellate. You also save a lot of bandwidth and vertex shader work by tessellating the geometry after the vertex shader. For skinning for instance this is a huge win since you only have to animate the low res mesh, regardless of actual detail level on screen. It does add hardware load, of course, but calling it "no real gain" is silly.
                              For the actual rendering it doesn't matter. Tessellation work is not for free. Hence it doesn't really matter if you have a vertex shader which transforms geometry or a tessellation step afterwards which has to tap into texture units and manipulating triangles producing new triangles.

                              Nonsense. You pay for it every time you draw the geometry. It's cheaper to expand the data after the vertex shader stage than reading all that geometry from memory every time. ATI hardware is already generally bandwidth bound, so stuff like this helps.
                              Maybe it's cheaper after the vertex stage to fuss with geometry but you fuzz with a lot more geometry than otherwise. Many small things can be as expensive as a few heavy things.

                              Parallax mapping, which you'll need to produce results similar to tessellation even in a deferred renderer, can't produce results nearly as good as properly tessellated geometry unless you go completely overboard with normal map samples. You'll have warping and heavy aliasing and it won't play nice with multi-sampling either. Tessellation is just better.
                              You contradict yourself. First you say that tessellation is based on the normal map information and now you say the resolution is too low to do a proper normal mapping. The only difference between the two techniques is only that with tessellation objects stick out of the surface not just look like ( from a steep angle ). But this sticking out causes a lot of other problems since objects align with the non-tessellated geometry but rendering is with. Clipping and penetration are the ugly results of this. But in general if the geometry and normal maps are done properly the difference to full tessellation is not huge but the speed difference is.

                              Comment


                              • #45
                                Originally posted by Dragonlord View Post
                                You contradict yourself. First you say that tessellation is based on the normal map information and now you say the resolution is too low to do a proper normal mapping.
                                I said nothing about resolution. I have no idea where you're getting that from.

                                I said you need to do a huge amount of texture samples per pixel to have accurate parallax mapping. You're basically raytracing the height/normal map and that needs a fair amount of samples to be accurate. With tessellation you do one sample per post-tesselation vertex in the domain? shader (i forget) and displace the vertex based on that.

                                And that's even ignoring the aliasing problems you have with parallax mapping, especially around silhouettes. Tessellated geometry benefits from MSAA just like any other geometry and as such looks much better. With parallax mapping you basically have to supersample every height-map lookup, and you still can't do anything about the silhouettes (if you're even doing them properly, which today is unusual.)

                                Originally posted by Dragonlord View Post
                                The only difference between the two techniques is only that with tessellation objects stick out of the surface not just look like ( from a steep angle ). But this sticking out causes a lot of other problems since objects align with the non-tessellated geometry but rendering is with. Clipping and penetration are the ugly results of this.
                                That depends entirely on how you build your collision mesh. It's already usual to have a separate low-res collision mesh so it's not exactly difficult to take displacement into consideration when building that.

                                As for speed, yes parallax mapping the way it's implemented in most engines these days is probably faster, but it also looks considerably worse. Apples and oranges. Tessellation provides much better quality for a minor performance hit (comparatively speaking.)

                                Comment

                                Working...
                                X