I finally started working on a skin animation exporter with the hope of merging it with the existing exporter but ended up re-writing the entire exporter.
I wrote a few stand alone scripts over the weekend just to test the python API and see how I can integrate it with nebula. Initially I didn't know much about nebula's animation files and I had to figure it out the hard way, by looking at existing code, specifically the 3DS Max exporter which was a lot of help. Nebula's documentation also offered some help.
By yesterday, I could export animations but my script still has a problem exporting the initial skeleton's pose. I posted my problem on blender's forum and went on with re-writing the rest of the exporter.
The mesh exporter is pretty much done and I just started working on adding animations yesterday. I've already run into a problem with transform animations though, I cant figure out how to get key frames from a blender object IPO yet but I'm looking into it. In the mean time, I will work on skin animation support, getting key frames for this is pretty straight forward, I wish it was as straight forward for object animations.
Wednesday, February 20, 2008
Wednesday, February 13, 2008
Back to Nebula 2
After a long while, I've gone back to developing with Nebula2 again. I've wanted to work a game for a while and I've been waiting for the perfect time, with the perfect team in the perfect weather but I just realized this will never happen. I need to work with what I have now and build from there.
We organised our first team meeting to get things started and I'm pretty happy with the progress, it was nice to have so much enthusiasm in one room. We managed to come up with at least a basic plot and assign roles in the team. We have as our project manager, Debra, one of the harshest (is that a word?) women I know, she should keep us in check. Bharat is in charge of the storyline and gameplay. We have 2 artists on the team, Dan and Mike. We are still considering a 3rd guy as a concept artist. I will be as the technical director/lead programmer.
We would eventually like to game to run on Nebula3 but as we wait for it to be stable, we decided to go with Nebula2 for now. Nebula3 might be the next best thing but I think Nebula2 is still way ahead of many engines today.
We are yet to settle for a title so for now its just project samurai, no points for guessing what its about.
We organised our first team meeting to get things started and I'm pretty happy with the progress, it was nice to have so much enthusiasm in one room. We managed to come up with at least a basic plot and assign roles in the team. We have as our project manager, Debra, one of the harshest (is that a word?) women I know, she should keep us in check. Bharat is in charge of the storyline and gameplay. We have 2 artists on the team, Dan and Mike. We are still considering a 3rd guy as a concept artist. I will be as the technical director/lead programmer.
We would eventually like to game to run on Nebula3 but as we wait for it to be stable, we decided to go with Nebula2 for now. Nebula3 might be the next best thing but I think Nebula2 is still way ahead of many engines today.
We are yet to settle for a title so for now its just project samurai, no points for guessing what its about.
Monday, January 21, 2008
CG Shaders and FBO
After getting textures working I wanted to have my test application run using nebula3's application framework. The only way to have this working was to implement shaders and render targets.
Nebula3 makes use of effect states and glsl does not have an effect framework so it was a natural choice to use Nvidia's CG. Nvidia just released CG 2.0 so I decided to give it a try. I have to say, CG's API is pretty straight forward and easy to work with.
According to the CG specification, semantic names are case-insensitive and CG returns semantics in uppercase so if e.g. I define a semantic as ModelViewProjection in my shader, CG returns it as MODELVIEWPROJECTION . This is what I feed into nebula as a the shader variable's semantic when its created. The problem comes in when a semantic is hard coded into the application as ModelViewProjection. This throws an error since the variable ModelViewProjection cant be found. As a temporary solution, I've changed all references to shader variable semantics in the source code to upper case.
Whever a ShaderInstance is created, a clone of the effect should be created, as of this writing, CG's cgCloneEffect function is not working, as a temporary solution, whenever a shader is loaded from file, I keep a copy of the source in the shader. Whenever a shader instance is created I re-create the effect using the source in the shader.
Apart from that, I'm generally happy with CG 2.0.
As a render target implementation, I've used Frame Buffer Objects(FBO), it was pretty straight foward to set it up but there are still issues I need to fix here and there. e.g. I'm testing it on a Radeon x1650 that does not have the None Power of Two(NPOT) extension which makes rendering to a 1024 x 768 texture very, very slow. The card however supports the texture rectangle extension so when I bind a rectangular texture as a render target the rendering works fine. But another issue rears its ugly head, rectangular texture coordinates are addressed using the textures pixel dimensions not the usual 0...1 range.
Still pondering on this one but I think Ill set it up such that if the hardware supports NPOT, setup will be done normally, if the hardware has the rectangular texture extension but not the NPOT extension, a rectangular texture will be used and if the hardware supports neither of the two, some sort of pixel padding could be used to make the texture a power of two (have to research on how to do this).
Finally here is a screenshot of the testviewer application running on CG shaders.
Nebula3 makes use of effect states and glsl does not have an effect framework so it was a natural choice to use Nvidia's CG. Nvidia just released CG 2.0 so I decided to give it a try. I have to say, CG's API is pretty straight forward and easy to work with.
According to the CG specification, semantic names are case-insensitive and CG returns semantics in uppercase so if e.g. I define a semantic as ModelViewProjection in my shader, CG returns it as MODELVIEWPROJECTION . This is what I feed into nebula as a the shader variable's semantic when its created. The problem comes in when a semantic is hard coded into the application as ModelViewProjection. This throws an error since the variable ModelViewProjection cant be found. As a temporary solution, I've changed all references to shader variable semantics in the source code to upper case.
Whever a ShaderInstance is created, a clone of the effect should be created, as of this writing, CG's cgCloneEffect function is not working, as a temporary solution, whenever a shader is loaded from file, I keep a copy of the source in the shader. Whenever a shader instance is created I re-create the effect using the source in the shader.
Apart from that, I'm generally happy with CG 2.0.
As a render target implementation, I've used Frame Buffer Objects(FBO), it was pretty straight foward to set it up but there are still issues I need to fix here and there. e.g. I'm testing it on a Radeon x1650 that does not have the None Power of Two(NPOT) extension which makes rendering to a 1024 x 768 texture very, very slow. The card however supports the texture rectangle extension so when I bind a rectangular texture as a render target the rendering works fine. But another issue rears its ugly head, rectangular texture coordinates are addressed using the textures pixel dimensions not the usual 0...1 range.
Still pondering on this one but I think Ill set it up such that if the hardware supports NPOT, setup will be done normally, if the hardware has the rectangular texture extension but not the NPOT extension, a rectangular texture will be used and if the hardware supports neither of the two, some sort of pixel padding could be used to make the texture a power of two (have to research on how to do this).
Finally here is a screenshot of the testviewer application running on CG shaders.
Texturing
After a long break from nebula3 opengl development I got back into it after the holidays. My previous posts are on another blog http://larryweya.blogspot.com Blogspot have an option of moving my blog to a different email account which doesn't seem to work for me. It forces me to keep logging in and out which is really annoying so I decided to start a new blog.
Next on my list was textures, I was dreading this as I wasn't sure yet how I wanted to go about it. Initially, I thought it would be easier to use one of the open source image libraries. After trying to integrate FreeImage and OpenIL I decided to write my own parsing routines since this is a learning experience.
To start with I have only written a .dds loader (a subclass of a streamreader) which is so far working fine and supports some of the more common pixel formats (DXT1, DXT3, DXT5, X8R8G8B8, A8R8G8B8, A4R4G4B4, R5G6B5 and A1R5G5B5). The plan is to eventually have it such that the image loading class (StreamTextureLoader) keep some kind of registry that maps file extensions to specific loader classes.
From what I know, directx and nebula's texture coordinates have uv coordiante (0,0) at the top left corner while opengl has it at the bottom left, I thought I would eventually have to do some sort of flipping, perhaps of the texture on load and save time but oddly enough, the texture mapping is perfect. I had a problem with my post process rendering but this was easily fixed on the shader by deducting the v coordinate from 1 i.e. v = 1 -v;
Next on my list was textures, I was dreading this as I wasn't sure yet how I wanted to go about it. Initially, I thought it would be easier to use one of the open source image libraries. After trying to integrate FreeImage and OpenIL I decided to write my own parsing routines since this is a learning experience.
To start with I have only written a .dds loader (a subclass of a streamreader) which is so far working fine and supports some of the more common pixel formats (DXT1, DXT3, DXT5, X8R8G8B8, A8R8G8B8, A4R4G4B4, R5G6B5 and A1R5G5B5). The plan is to eventually have it such that the image loading class (StreamTextureLoader) keep some kind of registry that maps file extensions to specific loader classes.
From what I know, directx and nebula's texture coordinates have uv coordiante (0,0) at the top left corner while opengl has it at the bottom left, I thought I would eventually have to do some sort of flipping, perhaps of the texture on load and save time but oddly enough, the texture mapping is perfect. I had a problem with my post process rendering but this was easily fixed on the shader by deducting the v coordinate from 1 i.e. v = 1 -v;
Subscribe to:
Posts (Atom)