| |
| |
| |
|
Page: 1 2 3
Comments:
<0> Csgl best option for opengl in C#?
<1> hello
<1> could i ask about projection of 3d on 2d
<1> i read some time ago
<1> some example of rendering a 3d scene
<1> i would like to remake that myself having only 2d plotting functions
<1> i would like to make a cube
<1> and plot 3d on the screen wich is 2d
<1> can i get some help ?
<1> helo
<1> Kutulu w00t up ?
<2> eh?
<1> like..how are you dude ?
<2> peachy
<1> what would that mean ?
<2> like..fine ?
<3> im tring to split up my code.... GLfloat yrot; I need to set it from another file or header how would I do it ?
<3> trying to split up my keyboard code into another file
<3> nm extern
<3> **** I cant make it work
<4> a few ways to p*** cl*** Keyboard around is to use a singleton or to create an instance eg. Keyboard* kb = new Keyboard();
<4> and then p*** a reference updateModels(Keyboard& kb);
<4> or camera.update(kb.isKeyDown( UPARROW ));
<4> (ignore the bad syntax ;P)
<5> I'm having trouble deciding how to finish this interface for specifying geometry.
<5> arg
<2> whats left to do?
<5> well not much
<5> the problem is specifying bone influences for vertices
<2> well what is there to decide?
<2> ah
<5> I'm just being too meticulas about it
<2> what type of data is that?
<5> err meticulous... whatever.
<5> well basically it's a weight and an id
<5> float and int
<2> weight is between 0 and 1 or ..?
<5> for each value/pair, now each vertex can have up to 4 (currently)
<5> yeah.
<5> I was trying to make the interface generic enough that all of the data doesn't have to be 1 to 1
<5> I mean you don't have to repeat the vertex to use it again with a different normal
<5> for example.
<2> does it read it all from a buffer or some object like that?
<2> s/does/can/
<5> so then when you specify the index for the vertices of a face, you have to specify an index into each array.
<5> well, here's what the interface looks like so far:
<5> http://rafb.net/paste/results/RAfOkS67.html
<5> So you can either specify the data in arrays or in an immediate mode style
<5> but right now, I have it so you only need to specify unique weight/id pairs, and then the plan was to be able to specify 4 weight/id indicies per vertex (for now).
<5> but instead it's only one index so it's not quite right
<2> to be honest i wish there was a parameter for stride so i can interleave everything in a fat array :)
<5> there is.
<5> err oh
<5> for indices?
<2> i think you should try it the simple way first ;)
<5> which is?
<2> hang on, i don't grok this interface yet
<5> You can use a stride for data, I guess not indices though so far.
<5> Take your time.
<5> Basically the goals for the interface are to allow the user to specify data in a very generic way, without having to worry about how their data is packed too much. I wanted to support an array method of specifying data and indices, and an immediate mode version as well.
<2> yeah that sounds like a good idea; array stuff is copied regardless right?
<5> yep
<5> cause I don't want to risk them destroying it
<2> ;-]
<5> The immediate mode version is supposed to be the more flexible of the two methods
<5> allowing you for example to specify faces as "POLYGONS" as opposed to just triangles
<5> actually more accurately, "FANS"
<5> because that's how I expand them
<5> but the point is, if you have the data in quads it would be triangulated for you.
<5> or mixed quads and triangles and some strange 5 sided ones in there too whatever
<5> it handles it.
<5> The other thing I was just now debating in my mind was if the user wants to specify more than 4 weights, I could basically emmit the lowest and normalize the rest.
<2> conceptually, the array functions could boil down to a for loop over the array, calling stuff like adSurface_NormalIndex()?
<5> in case they accidentally have a few .001 weights or something
<5> yep
<2> that would work for all cases of weights? what if they don't make mistakes? ;-)
<5> so really the array functions are not that necessary
<5> well here's the thing about weights right now, there is a 4 to 1 ration of weights to vertices
<5> most all other attributes are 1 to 1
<2> well they could be implemented pretty easily just calling the other functions, rather than having to do the stride stuff manually
<5> except uvmaps which I have many
<5> yeah, so should I scrap arrays?
<5> well arrays might be nice for specifying data manually.
<5> like who ever does that though right?
<5> it's good in a tutorial though :P
<2> first thing i'd do if i was using animadead, and if you didn't have array functions, would be to add 'em :)
<5> heh
<5> This thing you're looking at
<5> do you know what it's for?
<2> but it wouldn't be critical
<5> It's actually not for specifying data to Animadead directly, it's actually a writer library
<2> 'influence' == 'weight'?
<5> influence == bone
<5> weight = weight
<2> k
<2> i have to ask silly questions like that .. since i haven't previously :)
<5> the interface allows you to specify generic data, and it will write the animadead formatted files for you.
<5> it's meant for exporters.
<2> ah ok. In that case arrays wouldn't be *necessary* as the exporting app might have no notion of them
<5> true.
<2> or some obtuse pseudoarray stuff
<5> in fact that's one thing that's troubling me.
<5> i'm quite sure most modeling apis will give you the data in arrays
<5> but I'm not sure I can make any ***umptions about how it's packed.
<2> personally i'd leave arrays as low priority unless a good portion of the apps that might want to export could use them - and even then lower pri than immediate
<5> for all I know it could be like a 2d array
<5> k.
<2> yeah, so the exporter code itself can sift through and call the immediate functions..
<5> yeah that's always the safest I think.
<2> you/someone could add arrays later, if necessary
<5> So, in my current implementation... immediate mode is sorta, kinda, a little bit... related to the opengl interface
<5> it keeps some states and stuff
<2> and anything you do with arrays will basically have the same functionality as the immediate mode stuff anyway, so it can just overlay it :)
<5> aye
<5> but if you have data in arrays that's already nicely formatted.
<5> it might be more efficient
<2> yeah, i remember liking what i saw a while back
<5> and the support might be easy
<5> but make a lot of ***umptions about the data
<2> yes, "might" and "might" and more maybe :)
<2> everyone can use immediate mode, try it first :)
<5> yes ok
<5> so about immediate mode then...
<5> right now immediate mode is begin poly and end poly
<2> (this is all IMHO, btw, this is still your baby)
<5> and you specify indices within that block
<5> yeah, but outside oppinions really helpful to ***ess usability.
<5> So, the thing is, this begin poly and poly is sort of different than the rest of the interface
<5> I could use instances, were you create a face instance and push data on that.
<2> the rest of the interface is just setting with no real states?
<5> like push a vertex, and then push properties for that vertex.
<5> it would be more consistent with the rest of my interface.
<5> um it uses some states.
<5> It's a little tricky to describe.
<5> Basically right now here's what's going on:
<5> all of the arrays right now, index, normal, vertex, and all of the specified uv map arrays are the same size
<5> that is guaranteed by vertex but I'll get to that.
<5> so when you do a begin poly, it gets the current size of the arrays
<5> and then whenever you specify any data other than a vertex it appends it to that array, but only if it's not already larger than the vertex array
<2> arrays are the same size per-surface?
<5> in other words, you can only push one value otherwise it overwrites the last value
<5> that's how I keep my state.
<5> oh the arrays I'm talking about are the index arrays
<5> they index the data arrays
<5> and there are multiple because the data arrays only potentially contain unique values.
<5> not gauranteed to be the same size like opengl
<5> know what I mean?
<2> k
<5> k.
Return to
#opengl
or
Go to some related
logs:
#beginner
#cisco
#visualbasic
#beginner
#solaris
#winxp
#unixhelp
#delphi
#cisco
#beginner
|
|