0
\$\begingroup\$

I am quite new to game development and currently developing a simple 3D game with MonoGame and Blender. The game is basically a 3D version of Pong.

At first I developed the models at a constant size (e.g. a sphere with radius = 1) and then added a scale when I rendered it to make it proportionate to the other objects within the world. That way it was easy for me to play around and find good sizes for the objects without having to go back to Blender.

However, when I started to work on collision detection, I realized that it now was a lot harder to figure out how large the object is, because I had to manually recalculate the size of the object in the game world according to the scale factors I used. I could not simply look at the model and take the size values from there.

While the calculations might have been rather easy with a simple sphere, it got trickier when I had models I scaled differently in different dimensions. For example I rescaled a cube to be 10 times longer than high.

Pretty much the same problem with rotation.

How is this usually done in projects? Is it better to create the model already in the final size in Blender, so you don't have to keep track of the objects size within your code? Or is it ok to scale the model in code? If yes, how do you keep track of the changes?

\$\endgroup\$
3
\$\begingroup\$

What you've described (authoring all your content to be normalized within a unit sphere) is not a common workflow. Generally, a reference frame is established within your modelling program (for example one modelling world unit is assumed to be one meter) and all objects are modeled against that reference frame. A building that is fifty times the height of a one-meter-tall character would be 50 units tall in your modelling program.

Keeping the relative size of objects intact in their source form is useful if your asset pipeline ever involves working with multiple assets as references within a larger scene, as is typical with many large games. For example, many cinematic sequences are authored by importing asset references for the various characters into a scene and manipulating them within that scene. This becomes more cumbersome if you then have to apply scaling factors to bring everything into correct relative frames.

It also means you have to store the appropriate scale for an asset somewhere, which is generally illogical if you could just store it implicitly in the asset data itself by modelling it at the actual size.

So basically, it is a far less confusing workflow to simply build assets at the proper size originally.

That said, it's entirely doable to build everything normalized and apply some scaling factor at runtime. It just introduces a lot of complexity for very little benefit (you're already transforming and rotating the geometry every frame, so scaling incurs no additional cost... but it also doesn't speed anything up). You can simply scale the pre-computed bounding volumes and other related shapes at runtime by the same factor you're scaling the render model by, if you want. It's just not very natural.

\$\endgroup\$
  • \$\begingroup\$ Perfect, thank you. It just felt more natural to me to do as much in code as possible, because I had no experience in Blender at all. But your explanation seems very logical to me and doing it that way should make things a lot easier. \$\endgroup\$ – magnattic Jun 20 '14 at 0:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.