| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> @_@
<1> Hey guys, i'm looking at speeding up my tri strip rendering and am wondering if there is anything similar to the primitive restart extension in opengl in directX
<1> b***ically a way to restart a tristrip without all the overhead
<2> If you have a 90 degree vertical perspective matrix. The ratio of the distance vertically from a point to the distance away from the point is 1:1 right?
<2> So every unit that you move away you grow a 2 units vertical (one positive and one negative), right?
<1> anyone know how UVAtlas compares nvidia atlas tools
<1> ?
<0> it is >=< it
<1> o_O
<1> anyone here familiar with texture atlasing
<1> i got a conceptual question
<1> if it's possible to take an object or multiple objects and place their textures on an atlas such that it's on the same texture then wouldn't you be able to combine the objects to become a single poly mesh?
<1> err not single-poly but a single mesh
<3> Salec, that's the whole idea
<3> only having to issue one draw call for them
<1> interesting
<3> or depending on the combinations needed, FEWER than otherwise
<1> i'm trying to figure out how/where I can put texture atlasing into my pipeline
<4> You want to do it in your toolset
<1> I could either do some post processing step on all my ***ets for creating texture atlases
<1> or I could do it during run-time
<3> its more of an art ***et thing... depending on spatial locality in the map for instance, you want to combine certain objects
<4> you really don't want to do it at runtime due to mipmap issues
<3> its no use to atlas together two objects that arent visible at the same time
<3> yeah Dr^Nick's right
<3> toolchain
<1> aav: that's the issue I see, for a game say where you have specific levels that could share the same models
<1> what do you do then?
<4> you not only have to generate the atlas at mip-level 0, you have to gen it at all miplevels
<1> have dupe'd models with modified UV coords?
<3> or store "instantiation" data only
<3> how to transform the model uv's into this particular atlas
<3> the atlases themselves would need to be pregenerated though
<3> like Dr^Nick said
<1> well the atlaes I could pregenerate fine
<1> but what about modifying tristrips?
<4> so pregen your atlases, update your tex-coords on the models
<3> you using vertex shaders?
<4> all as part of the tool
<3> otherwise just loop over the mesh and update all verts
<3> on loadtime
<1> for example say I have a model that contains 3 tristrips, the reason why they have these strips is because each one is using a different texture..BUT beacuse those textures are now on the same file, I could meld all tristrips into a single strip
<4> salec - yep
<3> right
<3> treat them as "sub objects", why call them strips?
<3> indexed triangle lists are nicer in most cases
<4> so you keep the first tristrip the same, add tri-strip-0-size to each offset in tristrip-1 and append the verts
<4> and then do it again for tristrip 2
<3> if you insist on strips, you can stitch them together
<1> but now with that sort of ***umption
<1> say this model is used in multiple levels where a different atlas is used
<4> why would you use different atlases?
<3> Salec, like i said, "atlas instances"
<1> a different level could contain many other models that have different textures
<3> treat each level like a new game in terms of atlasing
<3> well
<4> yep
<3> at least as far as separate objects go
<1> so make a specific version of that object for that atlas or leve?
<1> level
<3> yea
<4> you only want what you absolutely need in memory at any given time
<1> yea
<4> don't pack an atlas with textures that a level doesn't use.
<4> that said...
<4> you need to ensure your atlas coords are always the same
<3> and if you want to save disk space, store a generic mesh on disk and modify it at loadtime according to the atlas parameters for this level
<4> which isn't a problem if you're just swapping textures
<4> :P
<1> aav: that's what i'm thinking about..my biggest concern at that point is load times (granted everything I generate I can store in a cache folder)
<3> its just a loop over the vertex data
<5> hmm, activity
<3> nothing that should hurt at all
<1> true
<1> ok now as far as welding the strips together
<3> the disk IO will dwarf that cost
<1> i'm kinda stuck using strips at the moment since that's what the engine is built on
<4> Change it :D
<1> strips have no way of stopping and restarting though do they?
<1> I plan to later ;)
<0> s/later/today
<1> does DX support any sort of primitive_restart mode?
<1> kinda like what nvidia has for opengl primitives
<3> no
<3> you have to stitch
<1> damn ;_;
<3> http://www.everything2.com/index.pl?node_id=1470544
<3> like this
<3> seach for stitch within the page
<3> basically you do a little dance with the indices
<3> oh, are they indexed strips or not?
<3> hi ZeZu, Ghaleon
<1> indexed
<3> good
<0> ;D
<5> hey aav ;)
<3> then just repeat the indices like shown
<1> nice that should be fairly fast then
<3> well, not as fast as trilists probably would be ;)
<1> trilist?
<3> indexed triangle lists
<1> is that anything like a trishape?
<1> ah hehe
<3> :P
<3> with strips you can get at the lowest 1 vertex per tri
<3> ***uming an infinitely long strip
<3> indexed trilists can give you lower than that
<3> ive seen 0.6 at least
<1> wow
<3> all due to the post-transform vertex cache
<1> and that's fully supported on the card in dx9?
<3> its been supported since the earliest T&L hw
<3> geforce 1
<1> :o
<3> :P
<3> you have to reorder the mesh in a certain way though
<3> D3DX can help
<1> i'll check it out
<3> you need D3DXOptimizeFaces and D3DXOptimizeVertices
<3> in that order
<1> alright so I modify the model data at load time then?
<3> that might be slow
<1> while having atlases built beforehand?
<3> well
<3> actually, do the optimizations at load time yeah
<3> different gfx cards have different cache sizes
<0> I usually do that in the MeshViewer ;]
<3> and if you overshoot and ***ume a too big cache size, you suffer heavily
<1> what I'm thinking I could do is at load-time check the hardware caps for max-texture size then build atlases based on that
<0> ;X
<3> too small ***umption and its not optimal either
<1> then refine the models as they are loaded :D
<5> HPOS p***ed from vertex program to fregment program should be in screen coords right ?
<1> what do you mean by cache size?
<3> be aware that the largest possible textures may not be so fast
<4> I would ***ume max-texture size is at the very-least 2k by 2k
<3> vertex cache size
<0> most cards support 1024x1024
<3> those D3DX functions query the hardware
<3> and optimize the mesh accordingly
<4> Ghaleon - new cards support 4k by 4k
<4> even older hardware supports 2k by 2k
<1> Dr^Nick: The smallest max texture size supported by all DX9 cards is 2048x2048
<0> new cards support infinity x infinity
<4> 1024x1024 is quite outdated
<1> Nvidia cards all support 4096x4096
<3> still, 2048x2048 might not be so fast for various reasons
<4> salec - right :) ***ume 2k by 2k
<3> but it could be worth it for batching
<1> but but..why not go 4k by 4k if i can do it?
Return to
#directx
or
Go to some related
logs:
query analyzer wine
pxe-t01 debian
#nhl
#nhl
#dsl
wp-mail.com
#beginner
#politics
#politics
#gamedev
|
|