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 ... 260 261 262 263 264 265 266 267 268 269 270 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 365

Query Failednbohr314
Wednesday, August 18, 2004

How manny other hidden capabilities does the R300 based tech have... Is the instancing truly supported in PS2.0b or does this technique require the "texture-format instancing" hack

MesserFuerFrauSchmid
Wednesday, August 18, 2004

Well, well I really would like to see Humus's answer on Remji's question now. Before he claimed it has no impact I wonder if his opinion changed since it works with ATI now as well. Since I think instancing is a really cool feature and I can think of many nice things doing with it. If games benefit of it depends much on the sort of game and engine. 3D RTS games would definitly benefit most of it since there you have normally a large amount of simular objects (units). Also a game with lots of vegetation (e.g. Far cry) would. Games which won't are Doom3.

Da3dalus
Wednesday, August 18, 2004

Nice one

Nico
Wednesday, August 18, 2004

GeForce6800 latest drivers (61.77):
1 (instancing): 277 fps
2 (shader): 333 fps
3 (vertex buffer): 350 fps
4 (vertex array): 155 fps
5 (draw calls): 97 fps

(15k particles, 1152x808, 32bpp).
Vertex Buffer is fastest???

Did you take a look at Uberflow (http://wwwcg.in.tum.de/Research/data/Publications/eghw04.pdf)?
Can you guess how much faster Uberflow would be?

Thanks for a new demo

Remij
Wednesday, August 18, 2004

Very nice Humus.

Do you think instancing will make THAT big of a difference in upcoming games, or are we looking at 1-3 fps at most?

Keep up the exellent work! =D

Humus
Saturday, August 14, 2004

Look in TexturePacker.cpp for the code. It's very simple. Sort of the idea behind a BSP tree. To make it work the best with as little wasted space as possible, don't pass it all sorts of widths and heights, but round to closest multiple of four or to the closest power of two or something like that, and sort your polygons for size first.

ViLiO
Friday, August 13, 2004

Hmmm,

Yea that is what I currently have in my own engine and the shadows are working fine. I haven't tried implementing soft shadows yet because I am still ironing out some bugs (namely texture bleeding). I plan to completely rework my model format as I currently just work with a triangle pool and create a lightmap for each triangle (this results in 2 identical lightmaps if the triangles make up a rectangle).

I was mainly interested in the way in which you packed the lightmaps. I can't find any wasted space. I have read a couple of articles on similar forms of packing, but never seen any code which does it.

Looks like I will be reading your code for many days to come

Again I must say, great demo.
Also, your finding of such a performance boost in the doom 3 shaders, but only for ati cards is hilariously ironic as you have previously stated that you didn't get a job at nvidia (shadows that don't suck) and went to ati. Oh how nvidia must be regreting not employing you

Thanks,
ViLiO

(apologies for the butt kissing lol)

Humus
Friday, August 13, 2004

It's fairly simple. Just make a BSP tree of the geometry to be able to do fast "collision detection". Then from each point you're evaulating the light, check if the line between the point and the light intersects any geometry. If it doesn't, you're in light, otherwise you're in shadows. Repeat for a few hundred samples within the light volume and you have a soft shadow.


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