New features, my suggestions and findings thus far.
Well folks, I have figured out what needs to change in order for the indexing to work correctly. It seems that some of the file loaders are not checking for duplicate points when loading them. My goal today is to modify that. The reason you ask, well unique vertices means faster rendering, as well as being able to build much longer triangle strips. I have looked through the rest of the engine, and I dont think changing these will cause any problems. So YAY.
Other than that, the strippifier is working fine w/the exeption of the DX renderer. Good news is it renders, bad news is it renders WRONG, but I will fix that today as well (I think im grabbing the wrong start address for the vertex table), but like I said, I am NOT a DXer so this is a learning curve lol.
Other than that, the strippifier is working fine w/the exeption of the DX renderer. Good news is it renders, bad news is it renders WRONG, but I will fix that today as well (I think im grabbing the wrong start address for the vertex table), but like I said, I am NOT a DXer so this is a learning curve lol.
Ok, decided NOT to modify the actual mesh loaders, but instead I simply remodified the CSceneManager.cpp to index the strips better. This way any future file loaders will work without any modifications to match mine. The draw back to this is that some of the mesh file loaders would be better off reworked a bit, to improve NON strippified mesh buffers.
Other than getting DX to work flawlessly, I am done with the integration, as well as updating opengl to use CVAs. I should be able to fix the DX stuff today or tommarow, then I will get this out to you all. Note: I havent applied any patches etc to this build, so it is simply the 4.2 build with my code added. So any patches will have to be applied afterwards.
Other than getting DX to work flawlessly, I am done with the integration, as well as updating opengl to use CVAs. I should be able to fix the DX stuff today or tommarow, then I will get this out to you all. Note: I havent applied any patches etc to this build, so it is simply the 4.2 build with my code added. So any patches will have to be applied afterwards.
Well, I have moved on to my next integration, which is creating a *Cartoon* material. I think this might be a littler harder than I had thought.
Why? you ask? Well, in order to make this work, I need to update the vertex colors of every object that is visable, and has moved since the last time it was visable. So, first I have do determin a way to do that (shouldnt be to hard), but since irrlicht uses mesh buffers, and different objects can share the same buffer, it would either need to load multiple buffers of the same objects, OR update each share buffer EVERY time one of the objects is rendered. Also, I would need to determin where in the scene the lights are each time an object moved (once again not that hard), but I think all of this will add up to be a little slower than I want it to work. I will keep attempting it though.
Why? you ask? Well, in order to make this work, I need to update the vertex colors of every object that is visable, and has moved since the last time it was visable. So, first I have do determin a way to do that (shouldnt be to hard), but since irrlicht uses mesh buffers, and different objects can share the same buffer, it would either need to load multiple buffers of the same objects, OR update each share buffer EVERY time one of the objects is rendered. Also, I would need to determin where in the scene the lights are each time an object moved (once again not that hard), but I think all of this will add up to be a little slower than I want it to work. I will keep attempting it though.
W/ toon shading, the camera placement dosnt matter. You only have to update the actual *TOON* coordinates (in this case the color values) when the light moves, or the object moves, since the values are based on the direction/angle of the light as it strikes the object. Basicaly think of them as TextureCoords that are dependant on Light Position. So camera movment has NO effect on the object, it will be rendered correctly no matter where the camera is.
With that said, does anyone know of a way to get a pointer to ALL of the lights in a given scene? Since the lights are SceneNodes, it would be very dependant on how the user named/initiallized them etc. But is there a way to simply grab all the active light scene nodes? Not just the visable ones?? In order to make this work, that is kind of what I need.
OR, lets take a vote, would it be best to do that? (Meaning grab the lighting from the global scene, which could cause time issues if there are ALOT of lights), OR... I could introduce a NEW SceneNode altogeather, built off of the AnimatedMeshSceneNode. In that method I would simply add a function to add/remove lights (well light positions, only used for reference to build the toon coords) to and from the node itself. That way, CPU ticks would be minimized. But I still run into the shared buffer problem stated a couple posts ago. So I might have to create a BOOL value for creating the Node, that states if this is a SHARED mesh or not, this would GREATLY reduce the amount of CPU ticks since we wouldnt have to update the Toon Coords (a hand full of crossproducts for EACH vertex) each and every frame, if it isnt shared. What yall think?
With that said, does anyone know of a way to get a pointer to ALL of the lights in a given scene? Since the lights are SceneNodes, it would be very dependant on how the user named/initiallized them etc. But is there a way to simply grab all the active light scene nodes? Not just the visable ones?? In order to make this work, that is kind of what I need.
OR, lets take a vote, would it be best to do that? (Meaning grab the lighting from the global scene, which could cause time issues if there are ALOT of lights), OR... I could introduce a NEW SceneNode altogeather, built off of the AnimatedMeshSceneNode. In that method I would simply add a function to add/remove lights (well light positions, only used for reference to build the toon coords) to and from the node itself. That way, CPU ticks would be minimized. But I still run into the shared buffer problem stated a couple posts ago. So I might have to create a BOOL value for creating the Node, that states if this is a SHARED mesh or not, this would GREATLY reduce the amount of CPU ticks since we wouldnt have to update the Toon Coords (a hand full of crossproducts for EACH vertex) each and every frame, if it isnt shared. What yall think?
well, since you're directly editing the vertex data for the mesh based on it's scene node's position in the scene, doesnt that mean that you CANT share this mesh? dont you HAVE to have multiple copies? otherwise the'll all only have 1 lighting pattern.
while you may be setting it N number of times, you'd only see the last modification, and you'd see it on all nodes using this mesh. unless im not understanding this properly (and of course, you're right about camera-independance, duh).
while you may be setting it N number of times, you'd only see the last modification, and you'd see it on all nodes using this mesh. unless im not understanding this properly (and of course, you're right about camera-independance, duh).
a screen cap is worth 0x100000 DWORDS
Well, I think you might be right about that one, since irrlicht puts everything into a render list, then renders everything at once, it will be IMPOSSIBLE to share the mesh buffers w/one another. Hmm, well that sucks. I guess I will have to create a totaly new Node type, and part of the node creation will have to be to create a new mesh buffer no matter if its in memory or not. That kind of bytes (bad pun, but I thought it was funny, lol).
So in doing so, I will also make it so, when you create the node itself, you add light positions directly to it, then when you want to update a light position, you will be able to call it in your scene, then simply send the new data to the node itself, only problem will be make sure you remember which scene light corrsponds to which node light.
Thanx keless, That was a pretty hefty oversight. Oh and by the way, thanks for the DX link, helped ALOT.
So in doing so, I will also make it so, when you create the node itself, you add light positions directly to it, then when you want to update a light position, you will be able to call it in your scene, then simply send the new data to the node itself, only problem will be make sure you remember which scene light corrsponds to which node light.
Thanx keless, That was a pretty hefty oversight. Oh and by the way, thanks for the DX link, helped ALOT.
sure thing. and NP about that DX stuff-- it was just a google search, i didnt even look at the .zip, lol
as for keeping track of lights-- this should basically end up the way I am keeping track of triangle selectors in my code (which uses basic IrrLicht collision detection).
all its going to do is keep a list of light scene node pointers. you should probably create a lightnodepointerarray or something, similar to IMetaTriangleSelector, which keeps a list of TSs which you can add and remove from.
its a little bit of a pain, since to remove one object, you have to remove it's TS from all the other objects-- but you're dealing with lights which probably wont be dynamically added or removed, so it should be nicer.
as for keeping track of lights-- this should basically end up the way I am keeping track of triangle selectors in my code (which uses basic IrrLicht collision detection).
all its going to do is keep a list of light scene node pointers. you should probably create a lightnodepointerarray or something, similar to IMetaTriangleSelector, which keeps a list of TSs which you can add and remove from.
its a little bit of a pain, since to remove one object, you have to remove it's TS from all the other objects-- but you're dealing with lights which probably wont be dynamically added or removed, so it should be nicer.
a screen cap is worth 0x100000 DWORDS
Well folks, the tri_stripper code is done, now all I have to do is find a place to upload it to, or you all can simply email me at beavis@rochester.rr.com
I will try to start sending them out by tommarrow (I want to make sure all my changes are noted well.)
Thanx all.
I will try to start sending them out by tommarrow (I want to make sure all my changes are noted well.)
Thanx all.
-
kburkhart84
- Posts: 277
- Joined: Thu Dec 15, 2005 6:11 pm
Holy crap!
Wow, blast from the past. I am so sorry guys. Its been a LONG time since I have been working on game code. Long story short, life got in the way, LOTS of things changed all at once (UNDERSTATEMENT), and I never got the chance to get back into things. I have just recently "re" taken up a love of game tinkering and was checking up on my favorite engine (irrlicht of course) and I realized I left a project half done!!!....!!! I know that I did finish this code, and had it working %100 before I got swept away, and I know that I sent the code out to a few people within the community, but I have NO idea who anymore because the email address I used back then no longer exists. I will check my "archive" of backup CDs and see if I can locate the code for you all, but to be honest Irrlicht has changed so much since then without my code being inserted or maintained it will probably be need to be completely rewritten. That being said, if no one else has entered a tri-strip routine into irrlicht by now, im sure I might be able to find the time to do so.
Once again, WOW am I sorry guys, I completely dropped the ball on this one.
Once again, WOW am I sorry guys, I completely dropped the ball on this one.