The Ghost of Refactors Past…

…has come to hunt me once again. Although this time it’s not because of mistakes that I did. Instead, the problem lies in something that I missed completely.

Can you spot the problem in the following code?

void SomeObject::save( Stream &s )
{
   std::size_t count = getElementCount();
   s.write( count );
}

Well, it turns out std::size_t is NOT PLATFORM INDEPENDENT. And here’s the twist: I knew that since, well, forever, but I never paid any attention to it. That is, until it became a problem. And the problem was EVERYWHERE in the code.

First thing first. The C++ standard has this to say about std::size_t:

typedef /*implementation-defined*/ size_t;

 

What’s that supposed to mean? Basically, std::size_t may have different precision depending on the platform. For example, in a 32-bit architecture, std::size_t may be represented as a 32-bit unsigned integer. Something similar happens in a 64-bit platform.

Wait.

std::size_t is supposed to help portability, right? That’s its whole purpose. And that’s true, of course. There’s nothing wrong with std::size_t itself.

Check the code above again. Go on, I’ll wait.

So, whenever we create a [binary] stream to serialize the scene, we can’t use std::size_t because it’s just plain wrong. It will be saved as a 32-bit integer in some platforms and 64-bit in others. Later, when the stream is loaded, the number of bytes read will depend on whatever the precision of the current platform is, regardless of what was used when saving. See the problem?

This means that we can’t share binary streams between different platforms because the data might be interpreted in different ways, leading to errors when generating scenes.

For the past few years, my main setup have been OS X and iOS, both 64-bit platforms. But one day I had to use streaming on 32-bit Android phones and, as you might have guessed by now, all hell break loose…

Entering crimild::types

I had to made a call here: either we can keep using std::size_t everywhere and handle the special case in the Stream class itself; or we can make use of fixed precision types for all values (specially integers) and therefore guaranteeing that the code will be platform independent.

I went for the second approach, which seems to me to be right choice. At the time of this writing, the new types are:

namespace crimild {

   using Int8 = int8_t;
   using Int16 = int16_t;
   using Int32 = int32_t;
   using Int64 = int64_t;

   using UInt8 = uint8_t;
   using UInt16 = uint16_t;
   using UInt32 = uint32_t;
   using UInt64 = uint64_t;

   using Real32 = float;
   using Real64 = double;

   using Bool = bool;
 
   using Size = UInt64;
}

As you can see, crimild::Size is always defined as a 64-bit unsigned integer regardless of the platform.

Yet that means I need to change every single type definition in the current code so it uses the new types. As you might have guessed, it’s a lot of work, so I’m going to do it on the fly. I think I already tackled the critical code (that is, streaming) by the time I’m writing this post, but there’s still much to be reviewed.

New code already makes use of the platform-independent types. For example, the new particle system is employing UInt32, Real64 and other new types and–

Oh, right, I haven’t talked about the new particle system yet… Well, spoiler alert: there’s a new particle system.

You want to know more? Come back next week, then 🙂

 

 

 

Crimild v4.4.1 is Out!

Happy New Y…. ok, ok. Moving on.

Remember when I said I wanted to make “smaller releases more often“. Well, here’s the second one in 2017: v4.4.1

Before you ask, yes, there was a v4.4.0 that was released yesterday, but the newest one contains some last minute fixes and I thought it was appropriated to make a minor release just to include them.

Anyway, the major features available in this release are the improvements for offline rendering and multi-camera setup that I described in the previous post.

Also related to rendering, the Depth of Field effect has been improved to… well, to work correctly this time, using actual photography parameters. Check this out:

Screen_Shot_2017-01-29_at_1.06.15_PM.png

On the other hand, nodes in a scene are now updated in parallel thanks to the concurrency tools available since v4.3.

As usual, expect some other minor fixes and improvements as well. Check the full release notes for the newest version here.

Oh, and this time I did remember to update the demo projects in order to handle the latest changes, too.

Enjoy!

 

Rendering to Texture

Happy 2017! I know, it’s almost February, but better late than never, right?

[EDIT: I was so excited that this demo actually worked that I didn’t even realized this wasn’t the first post of the year]

Anyway, I just finished this demo and I wanted to share it with you. Simply put, I’m rendering lots of characters on screen using the impostor technique, which relies on rendering a single model in an offscreen buffer. Then, multiple quads are drawn using the output of that buffer as texture.

Et voilá!

In order to achieve this goal, I had to make some changes in how scenes are rendered (is this the first refactor of the year? No). Since we’re using multiple cameras, we needed a way to define which one is the main one (we cannot rely on the Simulation to that for us any longer). Also, a new render pass is required to draw the model on a texture. And so the OffscreenRenderPass (were you expecting something else?) was born. But that’s pretty much it.

As usual, this is a new feature and therefore… unstable. Do not try it at home (yet).

Bye!