Humus - Comments

More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 412 413 414 415 416 417 418 419 420 421 422 ... 431 ... 438

Query FailedMnemonic
Wednesday, May 28, 2003

This code breaks on Gigabyte ATI Radeon 9000.
It reports :
Unhandled exception at 0x6931e180 in InfiniteTerrain.exe: 0xC0000005: Access violation reading location 0x00000030.
in atioglxx.dll

I've tried several other demos (including my code), but it always crashes on same place.

I have Catalyst 3.4 drivers installed.

Also demo work fins on GF4 Ti42000, same exe without any modifications (Detonator 44.35).

Where's the problem ?

Doomtrooper
Wednesday, May 28, 2003

Humus as usual speaks words of the wise...well done.

Humus
Tuesday, May 27, 2003

The save would be in storage space and bandwidth, though maybe not so much in transform rate if you're truforming it up to the same amount of polygons as the original hires mesh. However, you don't really need to have that many polygons to get a good silhouette. For games you hardly need to care about the silhouette at all.

hornet
Tuesday, May 27, 2003

Truform eh? How would you have truform added to just the silhuette?
I suppose you could split the object into a silhuette-, front- and back- part each frame, rendering only the silhuette using truform... but otherwise wouldn't you end up subdividing the whole thing, gaining nothing (bump+truform = same amount of triangles)?

dirk
Monday, May 26, 2003

Concerning silhouettes: there was a paper at SIGGRAPH 2002 about that. Take a look at http://people.deas.harvard.edu/~pvs/research/silclip/ if you're interested. The basic idea is to built a helper tree to quickly find the silhouette and use stencil to cookie-cut the model to it. Doesn't work with interior silhouettes, but in general looks quite nice.

BlackSilver
Sunday, May 25, 2003

I personally don't agree with Nvidia decision, but I don't think that is so bad. The clipping planes question is very bad, but there isn't so sad since there isn't really gameplay on 3DMark, so there isn't anything that will be render slower than the benchmark, because don't exist a really game

Anyway, is unfair because ATI doesn't do the same thing

But in relation to the reorganization of the code I don't see anything wrong. This is the compiler driver job.
The remake of the code I think that should be unfair, but isn't really wrong since the 3DMark code never was fair with any Nvidia card.

Humus
Sunday, May 25, 2003

Well, technically, yes. Though the way the bumpmap is created is the interesting part. Unlike what is normally done when we call it "bumpmapping" where the bumpmap is painted by the artist this bumpmap is generated from actual geometry from a high resolution model, which makes the appearance much more realistic.

Massimo
Saturday, May 24, 2003

I waited nv35 hoping it would be fast. Looks like it's not. No matter, I was still holding for them.
Now, I know they joined the cheating bandwagon. I no more feel them right. I feel they made a very bad marketing move by doing this, their reputation will probably be badly hurt.
BTW, I begin to think that GeForces are getting plagued by their own success. There's simply too much things to support... I guess this is a reason because companies rise and fall.
It would be really good if one can get an ARB extensions from the beginning. Too bad it's not the case. Look at EXT_frag_shad. It is equivalent to ARB_v_p but the interface is bad. Sometimes nvidia had to go for NV extensions, it is the case of NV_tex_shad and NV_reg_comb. If only they allowed other vendors to use them...


General
	News 3D Pictures Textures Articles Cool stuff
Other
	FAQ About Humus
Other 3D sites
	OpenGL.org GameDev.net Beyond3D Rage3D
Programming info
	OpenGL extension registry NeHe