PDA

View Full Version : Codename 'Parhelia'...


Nappe1
11-Feb-2002, 15:33
http://www.gamestar.de/aktuell/news/news6417.html

that does not say much but take it as grain of salt... :smile:
and of course http://babelfish.altavista.com/ helps if needed. (as in my case.) :wink:

ChrisK
11-Feb-2002, 16:16
Well, they are straight out saying that it's just a rumour.

I have to say, that the many rumours that surround Nvidia and its offerings often contain some truth, but out of experience, I think that rumours concerning Matrox generally aren't worth much. They could just as well originate from the Matrox fansite.

Nappe1
11-Feb-2002, 16:18
ChrisK: you mean MURC?? :smile: well, I picked that link from there and nothing indicates this originates from there.

but as said, take it as a grain of salt...

ChrisK
11-Feb-2002, 16:51
Yes, I mean http://www.matroxusers.com .

I'm lurking on their forums from time to time. Weren't there multiple occasions of idle speculations from their forums ending up on the news pages of many websites? I thinks so.

I remember reading about an imminent release of the famous G800 there in late 2000.

By now it seems to me that Matrox rumours have a certain annoying Bitboys "quality" to them - there's never anything coming out for real.

DemoCoder
11-Feb-2002, 19:09
Probably the most interesting rumor is displacement mapping, however, I feel that these are probably based on Matrox's presenation at Meltdown. Not everything presented at Meltdown goes into hardware, but could in fact, been something that they were prototyping in a simulator. We all remember Talisman. :smile:

I have a feeling the first implementations of displacement mapping in hardware are going to be horribly broken (lots of visual artifacts, discontinuities, etc) and not very flexible. DX9 looks like a good start, but I bet they won't be usuable until DX10.

MfA
11-Feb-2002, 19:17
First of all I dont think everyone remembers Talisman :) Secondly, are you sure Talisman never made it to silicon?

Joe DeFuria
11-Feb-2002, 19:22
heh...I remember Talisman!

I can still remember in the nVidia NV1, 3D Labs GiGi "Gaming Glint", (remeber that one?) and S3 Virge days, people saying "wait until we have Talisman cards...and they'll also support that new thing from Intel called "AGP" that will eliminate the need for on-board memory! :wink:

Joe DeFuria
11-Feb-2002, 19:24
I have a feeling the first implementations of displacement mapping in hardware are going to be horribly broken

Yeah, but I'm sure we'll get some nifty tech demos using it. :wink:

Bentarr
11-Feb-2002, 19:46
Displacement Mapping. Hmmm.
I don´t know the meltdown presentation, but if there are not heavy optimisations running in the background, i cannot see this anywhere near possible (read: in any usable form) with today polygon counts. Or, it will look horribly with a low poly count as DemoCoder already said.

Maybe a map for terrain deformations like bluntly craters or something like that, but what about a brick wall or even more detailed objects?

Hyp-X
11-Feb-2002, 19:54
On 2002-02-11 20:09, DemoCoder wrote:

I have a feeling the first implementations of displacement mapping in hardware are going to be horribly broken (lots of visual artifacts, discontinuities, etc) and not very flexible. DX9 looks like a good start, but I bet they won't be usuable until DX10.


Do you think that ATI's first N-patch implementation is "horribly broken"? Because if misused it can create discontinuities?

As it turns out N-patches require some attention from the artist who does the model. The same is trivially true for displacement mapping. Like N-patches, DM has a crack when there is a normal discontinuity (edges). It can also crack when the mapping changes at a poly edge and the maps don't fit.

As for DX9 why do people imply that Microsoft invents new features and new cards implement these? It's actually more like hw manufactures create the new features in their new cards, and Microsoft exposes these through new APIs. So DX9 or DX10 has nothing to do with the Parhelia doing this feature buggy or correctly.

ChrisK
11-Feb-2002, 20:07
Talisman:

Yes, I remember that very well, in early 1997 I fully expected it to be released at some point, with Microsoft throwing their weight behind it and all...

BTW, :smile: Your mentioning of it has inspired me to take a look at my old CD-Rs and I indeed found an old document (from early 1997) detailing what Talisman was supposed to be. If you're interested, I've uploaded it to the webspace that comes with my internet account: http://chklassen.bei.t-online.de/Talisman.zip (it's a 316 KByte zipped Word document)

Interesting and... somehow familiar ("chunking"), isn't it? :wink:

Displacement mapping: I have a little trouble understanding how they want to do that. The methods of displacement mapping that I know require the geometry that is to be displaced to be already there, leading to very complex models with thousands of additional vertices. I somehow don't think this would be a usable solution on consumer hardware today. So how do they plan to solve this problem, generating the necessary geometry on-chip?

Hyp-X
11-Feb-2002, 20:10
On 2002-02-11 20:46, Bentarr wrote:
i cannot see this anywhere near possible with today polygon counts.


May I ask what are those poly counts?
Because I think today games have hopelessly low polygon counts.

Even a GF2MX can support 300 000 polys well above 30 fps. Yet most of the actual titles use far less than 50 000 polys. Quake 3 has like 10 000 (according to JC). When Epic said their demanding test scene uses as many as 100 000 polys, many peaple said "Wow, that many? That will surely be geometry limited!". Guess what? It's fillrate/bandwith limited even at 640x480! :smile:

nAo
11-Feb-2002, 20:16
So how do they plan to solve this problem, generating the necessary geometry on-chip?


I don't know for sure. I believe they are going to create new geometry till screen projected edges are below a fixed length.

ciao,
Marco

Joe DeFuria
11-Feb-2002, 20:18
ChrisK,

Wow...now that's a blast from the past! Thanks for the post. I was searching the 'net looking for that very same article. (I remember reading it years ago). I remember seeing the "required bandwidth" graphs and wanted to see how things panned out.

This is great:

A full up SGI RE2—a truly impressive machine—boasts a memory bandwidth of well over 10,000 MB per second. Its quite clear that SGI has nothing to fear from evolving PC 3D accelerators, which utilize traditional 3D pipelines, for some time to come.

Heh...looks like "Some time to come" ended up being 2002, with GeForce4 being the first to break the 10.0 GB/sec bandwidth barrier. :wink:

Hyp-X
11-Feb-2002, 20:19
On 2002-02-11 21:07, ChrisK wrote:
So how do they plan to solve this problem, generating the necessary geometry on-chip?


Yep. With linear tesselation or with N-patches.

http://www.microsoft.com/mscorp/corpevents/meltdown2001/ppt/Externals/Matrox_Displacement.ppt

Joe DeFuria
11-Feb-2002, 20:45
That's interesting...

I can see another case here that shows ATI and Matrox "supporting" one another. (A previous case being ATI and Matrox promoting a single pixel shader model for OpenGL.) If I understand this correctly, one way for developers make their models / geometry "displacement map friendly", is to make them N-Patch (Tru-Form) friendly.



<font size=-1>[ This Message was edited by: Joe DeFuria on 2002-02-11 21:46 ]</font>

Bentarr
11-Feb-2002, 20:47
I dont know if i fully understand your question.
What i reckoned was the following:
If you load up a Q3 map, for example, one with a bit heavier overdraw, so that you´ve got ~35.000 tris on the screen, a GF3 is slowing down to, i presume 50fps. May it be because of fillrate or geomety, the performance is limited even with this low poly counts.

What would happen if you throw a 800.000tris scene( 4 walls; corroded brick, ervery wall 200.000 faces, ceiling and floor bumped) on a NV30 like gpu? In any case i dont know but i presume the performance will drop like a stone.

Thanks for the link, btw.

Hyp-X
11-Feb-2002, 20:48
On 2002-02-11 21:45, Joe DeFuria wrote:

A previous case being ATI and Matrox promoting a single pixel shader model for OpenGL.


...vertex shader model...

DemoCoder
11-Feb-2002, 20:53
I guess I'm just a RenderMan <bleep>, but I dream of a day when hardware tesselates to micropolygons and the shading language is powerful enough to allow procedural displacement mapping.

Moreover, I dream that the hardware is efficient and tesselates adaptively so that more vertices are created nearer than farer, and that this runs so blazenly fast that you can use it all over the place.

Hyp-X
11-Feb-2002, 21:07
On 2002-02-11 21:47, Bentarr wrote:
What i reckoned was the following:
If you load up a Q3 map, for example, one with a bit heavier overdraw, so that you´ve got ~35.000 tris on the screen, a GF3 is slowing down to, i presume 50fps. May it be because of fillrate or geomety, the performance is limited even with this low poly counts.


Q3 is fillrate/bandwidth limited so the overdraw is the most likely problem in this case. That's why kyro2 got such high scores.


What would happen if you throw a 800.000tris scene( 4 walls; corroded brick, ervery wall 200.000 faces, ceiling and floor bumped) on a NV30 like gpu? In any case i dont know but i presume the performance will drop like a stone.


On Q3? Well, did you see the nv15 map?
I stopped in one of the very low poly corridor and loaded a bot. I was always able to tell where the bot was just by looking at the framerate. :smile: Read: Q3 gets CPU limited with high polycounts.

It's because the high polys was done with BSP, and the game is likely died in routines like collision detection. If high polys would be added just like additional "eye candy" models (not affecting gameplay directly), than no it wouldn't affect framerate much.

Hyp-X
11-Feb-2002, 21:15
On 2002-02-11 21:53, DemoCoder wrote:

I guess I'm just a RenderMan, but I dream of a day when hardware tesselates to micropolygons and the shading language is powerful enough to allow procedural displacement mapping.


You can procedurally "displace" vertices in existing vertex shaders. Actually DM is just a sampled scalar passed to the vertex shader, it's up to the shader to use it for displacing or whatever else it wants to use it for.


Moreover, I dream that the hardware is efficient and tesselates adaptively so that more vertices are created nearer than farer, and that this runs so blazenly fast that you can use it all over the place.


Your dream may come true sooner than you think! :cool:

mboeller
11-Feb-2002, 21:21
Hi ChrisK and Joe;

If you didn't know already here you can find additional information about the Talisman/Touchstone architecture and a few others too :

http://web.media.mit.edu/~wad/vsp/vspreview.html

Look at node 3 for the Talisman-info.


Manfred

<font size=-1>[ This Message was edited by: mboeller on 2002-02-11 22:23 ]</font>

Nappe1
11-Feb-2002, 22:34
wow... :smile:

I was few hours away and did miss all this conversation? :smile:

anyways, AFAIK, Matrox isn't creating so much memory bandwidth limited card than nowadays cards are. I have heard that they have memory bandwidth available as much as 256 bit DDR memory interface would give on running at 300Mhz speed. (makes little bit under 20GB/s) but I have now idea how they are gonna reach that memory bandwidth. There are a lot of possibilities: eRAM, MultiChip, 256bit interface or perhaps QBM/QDR memory?

and couple of more things... first, everyone is talking about making walls and other things with Displacement Maps, but that could be done also with bump maps (does not look so good though.) How about using Displacement maps for generating real time Height Fields?

second, If I have understood right, displacement mapping needs very powerful tesselation unit that is able to read vertice displacement values from bitmap and because of that, it needs to access that bitmap many times during tesselation. Am I right?
if yes, then how about making a "room" on chip for displacement maps so that tesselation unit can access that almost without latencies? (oh well, I could ask this directly too: would be there any advantage placing displacement maps on-chip memory?)


I really don't know if anyone is interested, but IF Matrox has been working with something, we should start seeing things before or at least on GDC. Next event on Matrox calendar is E3 and I don't think they are going to show G550 cards there. :smile:

EDIT: how on earth I was able to do so many typos to single post?? :wink:



<font size=-1>[ This Message was edited by: Nappe1 on 2002-02-11 23:45 ]</font>

Hyp-X
11-Feb-2002, 23:56
On 2002-02-11 23:34, Nappe1 wrote:

There are a lot of possibilities: eRAM, MultiChip, 256bit interface or perhaps QBM/QDR memory?


Well, we'll see...
But sometimes the simplest solution is the best. :smile:


How about using Displacement maps for generating real time Height Fields?


If you mean landscapes then yes that's definitely a good application.
Another idea is creating a very high poly model than create a matching low poly one and put the difference in a displacement map. Hmmm, doesn't that approach remind you of something?


second, If I have understood right, displacement mapping needs very powerful tesselation unit that is able to read vertice displacement values from bitmap and because of that, it needs to access that bitmap many times during tesselation. Am I right?
if yes, then how about making a "room" on chip for displacement maps so that tesselation unit can access that almost without latencies? (oh well, I could ask this directly too: would be there any advantage placing displacement maps on-chip memory?)


I doubt it will have comparable bandwidth requirement to simply texturing the object, so I don't see why should it be an advantage putting it on-chip. Actually this can be seen as a powerful geometry compression (like 32:1 !!!) saving a lot of bandwidth. Of course the geometry processing has to be very powerful to handle the amount of vertices/triangles that DM generates.



<font size=-1>[ This Message was edited by: Hyp-X on 2002-02-12 00:57 ]</font>

Nappe1
12-Feb-2002, 00:13
Yes, I really ment Landscapes while I used term Height Fields... :smile:

It has been a such a long time since I used that... (hehe :smile: it was/is known as Height Field on POVRAY 2.0 :smile:)

Nappe1
12-Feb-2002, 00:36
Hyp-X: :smile:

I have been following Matrox Parhelia project almost as long as Bitboys Avalanche project and eventhough their memory bandwidth lacks 15% behind Bitboys one, it is still the best choice from upcoming chips. :smile:

Hyp-X: but what is the simpliest way? maybe 256 Bit bus, but I surely hope that Matrox have found a new way to do it. Otherwise that card is going to be blast off also in the price range, not only in the benchmarks and games.

aww... Who wants to buy All-In-Wonder Radeon? there will be one for sale hopefully pretty soon.

3dcgi
12-Feb-2002, 03:32
On 2002-02-12 00:56, Hyp-X wrote:
If you mean landscapes then yes that's definitely a good application.
Another idea is creating a very high poly model than create a matching low poly one and put the difference in a displacement map. Hmmm, doesn't that approach remind you of something?


Yep. They used this technique on Lord of the Rings.

I see displacement maps being used frequently in the future, but their use will be limited in the next few years. I believe landscapes were mentioned in the Matrox presentation from Meltdown. It will probably be a while before we move past bump maps for fine details. Also the actual displacement map probably doesn't need to be a very high resolution. I can't remember what the presentation said about procedural displacement maps, but I think we'll see more procedural landscapes than anything. So texture reads won't be a problem in this case.

Bentarr
12-Feb-2002, 09:51
Off-topic warning. Sorry.


Because I think today games have hopelessly low polygon counts. Guess what? It's fillrate/bandwith limited even at 640x480!
- - -
Q3 is fillrate/bandwidth limited so the overdraw is the most likely problem in this case. That's why kyro2 got such high scores.

I´ve said nothing contrary to this. I wrote polygons, not vertices. Misunderstanding, i guess.

On Q3? Well, did you see the nv15 map?
I stopped in one of the very low poly corridor and loaded a bot. I was always able to tell where the bot was just by looking at the framerate. Read: Q3 gets CPU limited with high polycounts.

It's because the high polys was done with BSP, and the game is likely died in routines like collision detection. If high polys would be added just like additional "eye candy" models (not affecting gameplay directly), than no it wouldn't affect framerate much.

Any engine. I have not had a specific one in mind. I know the bunker map and i´ve seen exactly the same thing happen on another map.

What is a "not affecting gameplay direcly" model/object? Should not an engine still check for collision and such on whatever objects, except if you exclude them manually (like "detail" brushes out of the vis-set in Q3)?

Ant
13-Feb-2002, 08:50
Actually the G800 was released some time back, it is known as the G550, it is a bastardised shadow of its former self. Simply take Sisoft SANDRA and point it at a G550 and it will reveal its true identity to you!

Matrox screwed up the G800 big time by underfunding it and not fixing serious hardware issues. Whether they can ever recover from that is debatable, I'm not sure if they can, but if they do expect a strong resurgence from them at the top end (don't naturally associate that with gaming) of the market away from the bland OEMness they have been wallowing in for the last few years.

Nappe1 I'm quite interested in how you have been closely following the Parhelia project, have you been leading stealth Ninja operations in Montreal again? :wink:

Ant




On 2002-02-11 17:51, ChrisK wrote:
I remember reading about an imminent release of the famous G800 there in late 2000.

NTD
13-Feb-2002, 09:04
On 2002-02-13 09:50, Ant wrote:
Nappe1 I'm quite interested in how you have been closely following the Parhelia project, have you been leading stealth Ninja operations in Montreal again? :wink:


Well check out his homepage:
http://www.bol.ucla.edu/~rahjr79/ninja.htm

That's him in the middle ;-D

<font size=-1>[ This Message was edited by: NTD on 2002-02-13 10:04 ]</font>

PS. Ya'll do realize I'm only joking...

<font size=-1>[ This Message was edited by: NTD on 2002-02-13 11:11 ]</font>

Ant
13-Feb-2002, 09:12
So that's what Nappe looks like, I always imagined him to be blonde haired and blue eyed being a Fin :smile:

muted
13-Feb-2002, 15:37
if i wasn't that clumsy i'd probably go down there.. 20 minute drive maybe

but I'D KEEP ALL THE secrets to myself

they're just leaving all the budget/low-end market , they're already big in the video editing , and had the thus useless line of marvel cards axed

Nappe1
13-Feb-2002, 16:17
Nappe1 I'm quite interested in how you have been closely following the Parhelia project, have you been leading stealth Ninja operations in Montreal again? :wink:

Ant

Ant, Nice to see you here. :smile:

well, I think I should answer here " by reading MURC Crystal Ball forum." :grin:

but anyways,
I hear things... :wink: but as always, my sources will stay anonymous and I never trust on single source before I found another one confirming things.

Ant, I know that Murc's Crystal Ball -section is something like Reactor Critical (so very good source of rumours, but any facts? maybe some, but you have to read between the lines and after that use Bullsh*t filter and then you might have something for real. :wink: )

Still, MURC is something that at least I think being more than just a fan site and it's quality much higher than nVnews or Rage3D. (I have owned Matrox , ATI and nVidia card and after I sold my G400, I just haven't found the same quality things from nVnews nor Rage3D.)

and yeah, I am always on stealth mode and my middle name is "wall" :wink:

Dave Baumann
13-Feb-2002, 16:39
Most gratuitous use of smilies on the new forum award thus far give to Nappe1!

:razz:

Johnny Rotten
13-Feb-2002, 16:40
If you mean landscapes then yes that's definitely a good application.
Another idea is creating a very high poly model than create a matching low poly one and put the difference in a displacement map. Hmmm, doesn't that approach remind you of something?

Welcome to John Carmacks Doom technology.

Nappe1
13-Feb-2002, 17:20
On 2002-02-13 17:39, DaveBaumann wrote:
Most gratuitous use of smilies on the new forum award thus far give to Nappe1!

:razz:



Dave Baumann: thanks... :rollseyes:

well, enough...

Nappe1
13-Feb-2002, 17:32
On 2002-02-13 10:04, NTD wrote:

On 2002-02-13 09:50, Ant wrote:
Nappe1 I'm quite interested in how you have been closely following the Parhelia project, have you been leading stealth Ninja operations in Montreal again? :wink:



Well check out his homepage:
http://www.bol.ucla.edu/~rahjr79/ninja.htm

That's him in the middle ;-D

<font size=-1>[ This Message was edited by: NTD on 2002-02-13 10:04 ]</font>

PS. Ya'll do realize I'm only joking...

<font size=-1>[ This Message was edited by: NTD on 2002-02-13 11:11 ]</font>


LOL! :smile:

well, if anyone is interested, my picture can be found from IRC Gallery at http://irc-galleria.net/