Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

274 Neutral

About Jbs

  • Rank
  1. Is rotating the actual quads not allowed? It seems like you could just do that instead of rotating the uvs. If that isn't going to work, you could use a 2D rotation texture matrix that is setup for the angle of rotation. Something like: 2x4 [ cosAng, -sinAng, 0.0f, 0.0f ] [ sinAng, cosAng, 0.0f, 0.0f ]
  2. One thing you might want to investigate is adding a mipmap bias to that texture to sort of modify the mipping calculations. In essence, when the texel-to-pixel ratio is calculated to determine the mip level, you can apply a certain adjustment to the value which will affect the final level which is used. You might be able to set the bias such that it always picks your nth level. OpenGL Reference DirectX References
  3. Jbs


    [google] First Result
  4. Jbs

    adding arrays

    Quote:Original post by TheGilb Or if you were to change your dynamic arrays into C-style arrays of fixed size: *** Source Snippet Removed *** Even C++ template magic won't be faster than a decent memcpy implementation. Still, remember that the fastest code is the code that isn't written. I believe he wants to place the sum in the destination array, not the copy.
  5. Jbs

    Irrilecht Font Question

    It would be much better to ask this in the Irrlicht forums: Linky
  6. I do not think anyone has explicitly explained yet why you were receiving a stack overflow, so I'd like to clear that up in case you were still unsure. I'm willing to be that Init() was marked as virtual in some part of the class hierarchy. So, executing void Engine::Init() { Component *Parent = dynamic_cast<Component *>(&this); Parent->Init(); ... } really results in the cpu looking at virtual table of Parent and finding Engine::Init(). So Parent->Init() executes Engine::Init() instead of Component::Init(), which in turn causes an nonterminating loop and thus the stack overflow.
  7. 1) I'm not sure if this is the problem, but in my experience a black render is either an improperly bound texture or improperly bound texture coordinates. Have you tried boiling the shader down any? For example, first just return the sampled decal map and assure that works. Then, slowly build the shader up to find the breaking point? 2) My mistake, I thought you meant to cache the current and next keyframe on the gpu for interpolation, not the entire animation sequence. I'm not sure that such a large amount of data could be cached (or if you would have any guarantees that it would stay cached during the rendering of other materials.) Also, by doing it in immediate mode you could only cache at most the number of texturing units the hardware supported. If you get this to work and find some big performance wins, I'd love to hear about it.
  8. Check for static memory buffers and constants that must be packed into the executable. Also, if you are using C++, be aware that templated code must be instanced for each type that uses it. In other words, vector<int>, vector<myclassA>, vector<myclassB> all have unique code generated for them in the executable.
  9. 1) I'm assuming that by "it wont work" you mean the Cg program will not compile. What kind of error string are you getting with the failed compilation? In case you aren't sure how to get the error, (or for the reference of whoever else is reading this thread), you can register an error callback method with Cg that I have found quite helpful in these situations. For example, this is how I do it: bool ShaderFactory::Initialize() { ... // create the context sCgContext = cgCreateContext(); if( !sCgContext ) { Log::LogError( "Failed to create Cg context!" ); return false; } // get a suitable vertex profile sCgVertexProfile = cgGLGetLatestProfile( CG_GL_VERTEX ); if( sCgVertexProfile == CG_PROFILE_UNKNOWN ) { Log::LogError( "Failed to query valid vertex profile!" ); return false; } // get a suitable fragment profile sCgFragmentProfile = cgGLGetLatestProfile(CG_GL_FRAGMENT); if( sCgFragmentProfile == CG_PROFILE_UNKNOWN ) { Log::LogError( "Failed to query valid fragment profile!" ); return false; } // set callback cgSetErrorCallback( CGErrorHandler ); ... return true; } and CGErrorHandler is my callback defined as: #define BREAK_ON_SHADER_ERROR { do { __asm int 3 } while( GetFalseValue()) static void CGErrorHandler() { CGerror err = cgGetError(); const char * errStr = cgGetErrorString(err); const char * errListing = cgGetLastListing( sCgContext ); Log::LogError( "Cg Error!" ); Log::LogError( errStr ); Log::LogError( errListing ); BREAK_ON_SHADER_ERROR; } cgGetErrorString() will give you a fairly vague but sometimes useful error message. cgGetLastListing() will give you the exact compile error reported from cgc. The is usually the most helpful message. BREAK_ON_SHADER_ERROR is just a utility for forcing VisualStudio to insert a breakpoint if the method is called. 2) I don't believe that you can explicitly get access to more than one vertex position attribute within a Cg program. So, it would seem that in order to interpolate between two keyframe positions you are going to have to pack the additional vertex position in somewhere...possibly a texture coordinate unit. Of course this does not have to be done in immediate mode, but sometimes using the gpu to offload cpu workload requires some trickery.
  10. One quick idea would be to have the Factory class only parse the very top of the xml tree. So, let's say you had the xml: <Entity Name="Player"> <WorldTransform Translation="10, 0, 3"/> <Renderable Effect="Foo.fx" Mesh="Bar.x"/> <Body LinearVelocity="100, 0, 0"/> </Entity> <Entity Name="Trigger"> <WorldTransform Translation="10, 0, 3"/> <AABB Min="0 0 0" Max="10 10 10"> </Entity> The factory would be responsible for parsing only the name of the entity. The factory could then delegate the further parsing of the tree to sub factories which knowledge of the structure of the subtrees. So the factory would have a sub factory for the parsing of "Player"s and "Trigger"s. These sub factories would then be responsible for the instancing of the required sub classes.
  11. const Weapon* const WeaponPack::returnWeapon( const std::string& name ) { for(std::vector< boost::shared_ptr<Weapon>>::iterator iter = m_pWeaponPack.begin(); iter < m_pWeaponPack.end(); ++iter) if((*iter)->GetName() == name) return (*iter).get(); //if the name wasn't found, return a pointer to nothing return NULL; } I would also point out that it is a little awkward to return a raw pointer from this method if the intended usage of the shared_ptr was for reference counting. If a user calls returnWeapon() and caches the returned pointer for longer than the lifetime of the WeaponPack instance, the cached ptr will reference invalid memory. If the intended usage was just ensured destruction inside an stl container, this isn't as big a deal. Just to be clear, here is how the method would look: boost::shared_ptr<Weapon const> WeaponPack::returnWeapon( const std::string& name ) { for(std::vector< boost::shared_ptr<Weapon>>::iterator iter = m_pWeaponPack.begin(); iter < m_pWeaponPack.end(); ++iter) if((*iter)->GetName() == name) return (*iter); //if the name wasn't found, return a pointer to nothing return boost::shared_ptr<Weapon const>(); }
  12. Quote:Original post by Damocles Right, where to start... I have a system setup where I can draw one mesh, translate/rotate to a given offset and draw another mesh, translate/offset, draw a third mesh, and so on and so on. Each tertiary mesh inheriting it's parent's rotation/translation. So, I'm not completely sure I understand, but I think what you mean is you are doing a hierarchical transform. In other words, you transform are stacked onto top of each other, as in skeletal systems? I'm going to assume that is the case in my answer. Quote: I also have a cg script which handles vertex blending and vertex lighting. Now, when I send in the first mesh in a series of meshes, the lighting is perfect because the rotation matrix is the same as the world matrix. The problem is when the tertiary meshes go into the script, their normals get screwed up because they are still working as if they were in the world matrix. This messes up the lighting part of the script. My first thought was to multiply the normals by the matrix passed into the script (the same matrix used to multiply the vertexes) and then re-normalize, to get the new normal. This results in no lighting at all on the models - they are pitch black on every poly. So now I'm trying to figure out where the problem lies - I need to figure out how to get the vertex normal into the same matrix space as the vertex. Any ideas? And for reference, the cg script... (yes, it is mostly just the Nvidia examples botched into one script) *** Source Snippet Removed *** Another thing I'm not quite clear about is why you are lerping the normal like this: 'float3 N = lerp(normal, posN, keyFrameBlend);' I'm not very familiar with Cg, but does that say you are blending the normal and the position together? I'm not sure that is what you want to be doing. Instead, you want to transform the normals of your mesh by the current stacked transform. What I think you should do is take your ModelViewProj, which takes your model positions from model to projection space, and multiply your model normals by the inverse transform of this. Note that each time you move up the transform hierarchy you should change your ModelViewProj matrix that is passed into the Cg shader. For information on why normals are transformed in this odd way I googled this: http://www.unknownroad.com/rtfm/graphics/rt_normals.html I hope that helps!
  13. Jbs

    US mid-term election

    Quote:Original post by DrjonesDW3d ... *Applauds* You are absolutely correct. Show me a person who cares about the issues and stills needs to be reminded to vote and I'll show you a liar.
  14. Jbs

    Train robots to take over the world!

    Haha, what a good feeling. I saw your post and thought to myself, "hey, that looks interesting." I get into the post and see that you're talking about the game I made! hooray! I've been working on NERO for 2 years now, and have been the lead engineer for a little over a year. We're glad that it interests you! The build you can get from nerogame.org is a little over a year old, but it is currently the sole topic of a research class at the University of Texas so we expect a new release this December that will include better gameplay elements as well as a plug-in system for different learning methods. Anyway, thanks for the post, you made my day. :P Oh, also, these robots won't be taking over the world. P.S. Which course and university had you write a report about NERO? We're always interested when people show interest in us.
  15. [Edit: I take back my answer...seems I was wrong.] I tried compiling the line in question, and didn't seem to have any problems.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!