Monkey2-v1.1.07 out!

Hi,

After a bit of a delay, Monkey2 V1.0.07 is now out (from https://blitzresearch.itch.io/monkey2 as usual)! Actually, I was a wee bit unwell near the start of August which took me out of commission for a while, but I’m back now baby!

I did manage to get some pretty useful stuff done though, including:

Improved forward renderer

The forward renderer has been majorly overhauled/improved. This can now handle any number of lights, with or without shadows, but there is still room for improvement here. Currently, each light involves an additional rendering pass, which is not strictly necessary if shadows are not enabled, in which case several lights could be rendered in a single pass. This optimization will have to wait for later, but for now, as long as you keep number of lights/shadow casters down, the forward renderer should perform well.

The forward renderer actually runs in one of 2 modes – direct or indirect. Direct forward rendering draws directly to the display which means the app can’t apply ‘post effects’ unless they’re very simple. With deferred rendering, post effects can effectively ‘read’ the color/normal/depth buffers after the scene is rendered, but with direct forward rendering these buffers are not available so all post effects can really do is alpha blending/additive etc style effects. So I added the indirect forward rendering mode to allow for a wider range of post effects. With indirect forward rendering, the same rendering algorithms are used, only the screen is rendered to an internal offscreen color/depth target which can be accessed by post effects. It’s sort of like a half-assed deferred renderer. The range of effects possible with the
indirect forward renderere is still more limited than with a full on deferred renderer whcih has complete access to output colors, positions, normals and specular, but it’s better than nothing.

Activating the forward renderer is a little klunky right now. You need to do something like this in Main():

This is a bit of a mess and will be cleaned up in future.

Point light shadows

I’ve also finally got point light shadows working. This wont be terribly fast yet (shadows aren’t) because it needs to render the entire scene to 6 side of a cube map. Future optimizations here will include culling (only render what’s in light range) and the ability to ‘mask out’ cube faces. This masking can also be used to create spot lights where only one cube face really needs to be rendered. You could also create ‘dual spot lights’, ie: 2 spot lights pointed in opposite directions (which only requires 2 cube faces).

The algorithm here currently packs depth values in RGBA texels, as webgl doesn’t support depth cube maps. This works surprisingly well (at one point I had the whole engine using RGBA depth maps) although should be optional for HW that support depth cube maps (packing/unpacking RGBA pixels is a little ugly).

Linear vs SRGB colors

Another mojo3d issue which has been lurking for a while is the renderer’s use of ‘linear’ colors. As some users have discovered, the colors you assign to materials etc in mojo3d don’t look quite the same as they do in paint programs. The reason for this is that the mojo3d shaders assume color parameters are actually in ‘linear’ color space, whereas colors are usually specified in ‘sRGB’ color space. The main difference here is that color intensity (brightness) is linearly proportional in linear color space, but not in sRGB space. Mojo3d internally converts texture colors from sRGB->linear space, but it doesn’t convert color constants – well it did’t. I have modified the mojo3d APIs so that any color property (eg: Material.ColorFactor, Scene.ClearColor) now assumes colors are always in sRGB space, and converts them as necessary. So now you can assume that any texture or constant color you pass to mojo3d will look the same as it does in photoshop etc.

As a side effect of all this, note that the direct forward renderer uses additive blending for lighting effects, but in sRGB color space intensity is not proportional, so the lighting effects in the direct forward renderer (which assumes target buffer is sRGB) are technically wrong! However, the difference is subtle and no more wrong than Blitz3D etc were. It’s just a compromise that needs to be made if you want to render directly to an sRGB buffer.

Particle systems

There’s a new mojo3d PaticleSystem entity too. This is actually just a container for a particle buffer and a particle material. A particle buffer contains the actual vertices that makes up the particle ‘cloud’, and has properties such as duration (how long each particle ‘lasts’), min/max velocity and cone angle. Particles are automatically added and removed to a particle buffer as necessary each time the scene is rendered. A particle buffer can be shared amongst multiple paticle systems, much the way a mesh can be shared amongst multiple model entities.

Currently, a particle system’s origin and orientation are locked to the actual particle system entity, so if you move the entity, all particles move with it. This can can look unrealistic depending on what you are doing, so particle systems are currently best suited to static things like torches on walls etc. However, it should be possible for each particle to have individual position/orientation in future, allowing particle systems to be attached to thrusters etc and to able to leave ‘trails’ etc. Actually, you can probably attach a particle system to a thruster right now and it’ll probably look OK with the right tweaks.

Mojo outline mode

I also added a simple outline mode to mojo. It doesn’t do anything terribly flash like outlined fonts or image edge detection (outline of an image is just a rect border) but I think it shuld be useful for visualization stuff. For a simple demo, I added outlines to the hellochipmunk/chipmunkdebugger banana.

Speaking of bananas, Ted2go now has a banana samples viewer which launches on the first run of Ted2go (or can be relaunched via help menu). This is already looking very nice, and will look even better once I’ve cleaned up the bananas a bit. Plus we need some 3d bananas, currently all 3d sample code is in tests dir in vaiours mojo3d module dirs.

And speaking of IDEs, the monkey1 mollusk IDE now has early monkey2 support. This is a nice, clean, very easy to use IDE (Windows only) and you can find it here: http://grudlux.com/mollusk/.

Finally, please also consider throwing nerobot (the author of Ted2go) a few bucks via paypal here: https://www.paypal.me/engor/10. He has done an amazing job of tweaking and polishing the original Ted2 IDE, a huge feat considering it uses a completely unique GUI system and a completely unique language. But it has proven to be an excellent ‘test case’ for monkey2 I think. It runs virtually identically on windows, macos and linux (to a degree not even Qt could manage) and has a ton of intersting things going on under the hood.

Anyway, that’s enough from me for now – here’s the new stuff in v1.1.07 VERSIONS.TXT:

***** Monkey2 v1.1.07 *****

Android min-sdk now 14 for android projects.

Added Scene.DestroyAllEntities.

Added new ‘instance’ uniformblock type for better (not great yet) instancing.

Enabled assimp FBX and BLEND loaders.

Sprites now compare with depth buffer.

Added Sprite.TextureRect:Rectf property for simple 3d sprite animation.

Fixed Texture.Flags setter.

Added simple outline drawing to Canvas, see: Canvas.OutlineMode, Canvas.OutlineColor and Canvas.OutlineWidth. See chimpmunkdebugger.monkey2 in hellochipmunk banana for demo.

Implemented point light shadows using rgba depth cube texturing for webgl compatibility. Slow, needs to do some culling.

Added ParticleSystem entity subclass. A ParticleSystem contains a ParticleBuffer and a ParticleMaterial, so you can creating multiple instances of the same ParticleBuffer with different materials. See mojo3d particles test.

Added LinearColors property to UniformBlock and Renderer. Material color properties now always in sRGB space. Changed Color.Gold etc.to compensate (they were linear colors).

Bye!
Mark