Jump to content
  • Advertisement
Sign in to follow this  
Vast

Unity Please tell me if this makes sense (skinning in software), simple question

This topic is 4812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey everyone. Long time viewer, first time poster. Anyway, I'd like to ask a question. I am rendering 20 Doom3 Imps, skinned in software, using a format almost identical to doom3 (converted to my format for more rapid loading, and organized under my model structure, nothing major really), and im getting 11fps. So then I think, what happens if I compile in release mode. I also turned off vertical synch to see how much performance i could count on and have in my budget, and guess what, Im getting a solid (almost solid ;), more like 95 ) 90 fps. So first question, is debug mode really THAT slow? I mean, 90fps drop to 11 seems a little unreal to me. Makes me think im doing something wrong. Im using VC++ compiler if that makes more sense. Another interesting fact, is that I am rendering just polygons with one decal texture, so _no_ advanced rendering, _no_ shadows, _nothing_ surrounding the models, so its just plain software-skinned models. That leaves me with like 30 fps to spend on physics, advanced rendering techniques - (bump mapping, specular higlighting, ppxl, embm, etc.) and shadow mapping and all, this is sort of sad. Oh and no logic yet either, so just simple animations on 20 models. EDIT!: I am also running it all from a scripting engine (mainly just calling C++ function at realtime). What are your opinions on the data provided below? Should I look for optimizations? And also is it POSSIBLE to use shaders to push skinning from software, to hardware (think doom3 MD5 model format)? I heard on some forums it was impossible, so I was wondering if anyone could confirm that. I've never really used shaders yet (ha) I was concentrating more on the design of the engine, and giving the oportunity to people with older cards to enjoy. Thats sort of sad considering I got myself a GF6600GT in June. Thanks a lot for any future feedback. Tim

Share this post


Link to post
Share on other sites
Advertisement
It isn't very clear in your post, but it's a very bad idea to run the game from the scripting system. Generally the scripting portion of a game will be event driven, and you should avoid doing heavy scripting work every single frame, and certainly don't put your game loop in the scripts or you will pay a heavy cost in the frame rate.

Share this post


Link to post
Share on other sites
Hey,
Thank you for a fast reply.

Well, I am trying to make my engine user-friendly, and yet closed-source, so would you happen to have any good suggestions on what I could do? The engine is also cross platform, so I would want to force a compiler onto the user's hands, so I was pretty much stuck to begin with.

I would appreciate all the suggestions.

Regards,
Tim

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It's fine to have some of the logic in the scripting engine as long as the really processor intensive stuff like the rendering calculations don't need to go through it.

Debug really is that slow. The purpose of debug mode is to allow you to clearly follow what the program is doing to find bugs. The compiler doesn't need to make any effort at speed. It can throw in extra code everywhere to monitor the program execution. In the optimized build you could have series of function calls that are optimized away, but the debug build can't do this because it needs to make it clear how the program is being run. This especially happens with complex systems like the standard template library which are made to be highly optimized but which use a lot of complicated code to make everything generic.

When you say you are doing skinning in software, what do you mean? The more advanced 3d games require the newer graphics cards to do the fancy graphics effects because they would consume too much processor time if they were done on the CPU. There are lots of tricks graphics engines use to offload work onto the GPU.

Share this post


Link to post
Share on other sites
Hi,

Thanks for the clarification. When I say I am doing skinning in software, I mean I am doing it on the CPU instead of the GPU. I haven't done much research into shaders (i know perfectly well what they are, and what they are used for, but I am not sure _how_ they are used, and all the details of using them) but I am quite sure they are the best way to speed things up.

I am trying to write a complex, advanced engine (and it's been rewritten about 600 times by now) and I desided that this time I should push off of the logic first, then the fancy graphical effects, as opposed to doing it otherwise (whatever I did before started with fancy graphics, ended with no logic). This time I also want people who do not have the latest cards, but cards that are still quite OK, such as GeForce 2, or GeForce 4 (the type that dont have shader support), I want people who have those cards to still play the games made with the engine.

Regards,
Tim

Share this post


Link to post
Share on other sites
Just as a sidenote, when I render everything without scripting engine enabled, I get only a 3 fps boost. so now its about 98-99 on the avarage. I think those 3 frames are worth a scripting engine, but I still should look into more scripting engines. I have recently became fascinated with java (I knew it for a while, but i started liking it just recently), and i am going to look for a language with a similar syntax and structure to use as a scripting language.

I would still hope someone would have information about hardware skinning of doom 3 models.

Thanks!
Tim

Share this post


Link to post
Share on other sites
This doesn't sound very odd at all. In my current engine when I'm using software skinning I'll end up with anywhere from 15-18 FPS in debug mode, but that jumps to a good 85 or so FPS when I compile in Release (at which point it's purely fillrate limited. I'm testing on an onboard chip.)

Yes, Debug really is that slow. Under the right circumstances, of course. Especially with things like Skinning where there is a lot of matrix math involved. In release mode the compiler ensures that your code takes a lot of little shortcuts and uses a billion little memory tricks to keep things speedy. It also tends to compensate for less-than optimal code in many cases. (For example, even if you didn't declare it as such, a good optimizing compiler will recognize when a variable can be declared as a const and make the appropriate chages without telling you) Since matrix math usually involves moving around a LOT of floats, it tends to be a great target for optimizations like that (and many others!)

Also, it doesn't hurt that when you're compiling in release mode it doesn't bother generating any logging/debug info.

Share this post


Link to post
Share on other sites
Hey,
Thanks for an informative comment. And while you're here, can I ask you something?

What would be faster, matrix math or quaternions for skinning a model?

I read somewhere that matricies need about 39 operations, while quaternions would need 41, so there an obvious little speedup, but its still a little sketchy whether it will improve my skinning much.

Thanks for feedback!

Regards,
Tim

Share this post


Link to post
Share on other sites
99% of the time if you're using quaternions for your animation you're going to convert them to matricies anyways for the final animation frame. The real reasoning behind this is simply that matrix math is a buiilt in part of your GPU, so it's easy to convert to shader skinning. If you're doing software skinning only, though, sure you can use quats. I doubt there would be much speed difference, though.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!