| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> and if I dont glClearDepth then it really messes things up while depth testing is on
<1> stop drawing magic triangles?
<0> gah.... I cannot seem to get my frustum and perspective set proper
<0> whats a good fov and aspect ratio ?
<0> 60 , 1 ?
<2> Aspect ratio of 1.0 would be for a square viewport
<0> how about wide screen ?
<0> bbaw
<2> Aspect = X/Y, simple enough
<3> or Y/X ;)'
<2> Is it? I never used gluPerspective actually, always built my own matrices :)
<3> it can be both
<3> depends on which is bigger, and how you want your image to appear
<2> Right, makes sense
<0> once you set your frustum you are staring down the z axis right ?
<2> An identity matrix would make you look towards -Z if you wish, yes
<0> how does the identity matrix know how to pop itself ?
<0> when I flush ?
<2> What?
<0> glFlush
<2> glFlush does not "pop" anything
<0> I see glLoadIdentity ..... I see nothing about clearing or poping it
<2> I think you really don't understand matrices
<0> good guess
<2> That function replaces the current matrix by an identity matrix
<0> say I made a square like so
<0> glVertex3f(-5 , -2 , -20);glVertex3f(5 , -2 , -20);glVertex3f(5 , -2 , 20);glVertex3f(-5 , -2 , 20);
<0> with a triangle strip... how would I set my frustum and junk to see it
<0> I dont wana give in and use the lookat function in glut
<2> You'll want to look towards Y or -Y to see that fully
<2> Do you understand how vertices are rotated by the lower 3x3 part of matrices?
<0> hmmmm
<0> I would say no but I know how matrixes work
<0> its just trig one way or another for rotations
<0> anyone know how to disable the mouse in sdl ?
<0> like lock it in my ogl window so I can keep moving
<2> I ***ume the cursor is hidden, you can bring back in the center by SDL_WarpMouse(), there might be a better way
<0> SDL_ShowCursor(0);http://www.libsdl.org/pipermail/sdl/2001-July/037177.html
<0> oops
<0> never eat prunes on a famished stummich....
<0> murphy's law #oneofem
<4> anyone know of an open-source package to generate minimal triangle strips from polyhedral models?
<2> Nvidia had a tool for this, I don't have the name or url handy
<4> ah, NVTriStrip. thank you.
<2> *nods* Right
<5> What's the most efficient way to render geometry anyway? Aren't strips and fans somewhat slower now because of VBOs since they require multiple calls, and it's faster just to stream the data in video memory?
<4> i would like to use VBOs but my particular opengl implementation lacks the extension
<2> If you just need to write paths with VBO support, grab Mesa ( software implementation )
<6> Return0 - Lists that are in vertex cache order.
<5> right. but what kind of lists?
<5> just triangles?
<5> I mean, if you use fan and strip lists, the cache hits would even be more efficient I think. (*pondering....* Well I think so anyway)
<5> Dr^Nick: So, indices in the same format as GL_TRIANGLES right?
<5> but organized for cache hits.
<6> fan at strips are not as fast because you have to issue multiple draw calls
<6> you want a set of vertices, and a set of indicies and you want to do some processing on these sets to ensure that vertex is re-issued while it is still in the cache
<6> err fan AND strips
<5> right
<5> I understand the concept behind the caching
<2> There was some extension to issue the indice -1 to start a new strip at any time within the same DrawElements call
<2> Not too sure how supported or used it is
<5> I'm just looking for the clarification that it's specifying 3 indices at a time for triangles.
<6> http://developer.nvidia.com/attach/6773
<6> Return0 -yes
<5> ok good. thanks ;)
<5> Hey Dr^Nick: Look the NV docs made the same typo: "...have to be transformed at lit again..."
<6> ahaha
<5> I'm SO far behind in graphics programming
<5> I let it slip through my fingers
<2> Are you? :) The last time I was "on the edge" of rasterization graphics were in the gf2mx days
<5> hehe exactly.
<5> I just recorded an awesome macro in visual studio, I had data layed out in comments and I needed to make a bunch of function calls that used the data, so I was able to generate a fairly large block in the macro going back and forth copying and pasting the data
<5> and then I ran the macro 6 times and it was very satisfying
<6> Hrm
<6> Even I'm out of touch, and I'm writing SH engines and such
<6> There's just so much going on right now no one person can be an expert in all of it
<6> not like the pre-programmable days when it was very straightforward due to limited power
<2> One can stay up-to-date, I just wandered on other fields
<6> Mal - not in all fields of graphics at the same time..
<6> and raytracing is sooo 80s.
<5> hehe
<2> Grah :). Maybe I should benchmark against Mesa on 1 million polygons for you
<5> You know what I haven't seen really done well a particle system driven geometry accumulation and simulation.
<5> Like snow for example
<5> where it accumulates geometry
<2> Raytracing could handle snow reasonably well, with all the internal light scattering and reflection
<5> not just the rendering of snow...
<5> I just want to see persistent worlds with much more dynamic state and weather effects that are more immersive
<6> Mal - raytracing is so limited
<6> and benchmark it against a good software rasterizer will you?
<6> (it will get its *** handed to it)
<5> I think it would be fun to make a tech demo of some sort, where snow accumulates well, and you can treck through deep snow where you sink into it, and footprints are more like holes than decals.
<6> Return0 - its been done..
<6> :p
<6> its pretty easy
<5> heh
<2> What's your software rasterizer of choice, Nick?
<5> I don't think it's been done well
<2> In fact, I expect proper raytracing to surp*** its performance way before 1 million polygons
<6> http://www.radgametools.com/pixomain.htm
<6> Mal - your expectations are wrong
<6> go google
<6> its been benchmarked
<2> I'm not recommending to benchmark against Pov-ray or whatever else
<6> http://www.transgaming.com/swiftshader.php <- maybe this
<2> ( Pov-ray does not do real-time rendering of primary rays on one million polygons )
<2> This is real-time on a good box : http://www.rayforce.net/lights01.avi Do you seriously think any software rasterization can match this, with the shadows?
<2> Good box as in dual-opteron dual-core
<6> its going to take a bit to load..
<6> but if I recall from the last time I saw this my answer was "definately yes. this is poor in comparison to what can be done"
<2> It's simple math. The cost of rasterization grows linearly with polygon count, cost of raytracing grows with a low base logarithm
<5> what do you think of project offset as far as utilization of next gen tech?
<5> http://www.projectoffset.com/downloads.html
<2> Nick, if you saw the video, do you seriously believe software rasterization can match this?
<6> Mal - Its still loading
<6> mal - yes, no problem
<6> it would get its *** handed to it
<2> I have a certain difficulty believing that, with shadows from 3 light sources
<6> it would be no problem
<6> ESP. if you were allowed to multithread it
<6> just because you don't believe it doesn't mean its true :)
<2> So I need a video of a million polygon model next :)
<5> not true*?
<5> I'm still using an ati 9800 pro :P
<5> hehe
<6> mal - you're not the only person working on raytracing
<6> tons of people are in academia
<6> and they're benchmarking against rasterization
<6> and the result is well known
<6> rasterization is FAR FAR faster
<6> sure, in some limit raytracing might be faster... but the constant cost is HUGE
<2> Who is working on raytracing? InTrace is about 100 times faster than pov-ray, and I'm 10 times faster than InTrace
<6> I don't think you understand that
<5> at work I have a geforce 7900 though
<6> Mal - Google for it
<5> pretty freaky
<6> tons of profs everywhere
<6> hell, even mine
<6> (my old undergrad supervisor)
<2> I don't think you understand the kind of crappy algorithms are used for raytracing out there
<6> we did all sorts of benchmarking
<2> With what raytracer?
<6> my own
<6> plus a few others
<6> But raytracing isn't actually faster :)
<6> see, people who say that ignore the math
<2> The math is comparing a linear progression against a logarithm
<6> not true.
<6> you're ignoring stuff.
Return to
#opengl
or
Go to some related
logs:
#dsl
#debian
#windows
necrosan
#nhl
#stocks
#windowsxp
#windows
userpasswd2
#computers
|
|