Roadblocks... Limitations with MMF

If I could have my own way I would swap out the mmf renderer with Please login to see this link., but it's really not easy to just swap out a rendering mechanism in a C++ runtime. I think there is some promise for the iOS/android/html5 runtimes in this respect, or any of the runtimes that compile the output because I can patch the code at build time. I think I can bring sensible 3D to MMF, it's just a shame I can't integrate it with the existing renderer so you can reuse all the existing displayed objects.

I have to port the extension over to a new SDK which is a pain, but I'm working through it. I also envisage updating to a later version of irrlicht could be problematic. There is one limitation to this which might render the whole process useless, and that's collision masks. I can't use collision masks for this if hardware acceleration is going to be of value. I'm not certain if the current 3D mesh is testing for fine collisions or not, but the process of generating collision masks will mean reading the pixels into memory, which is exactly what we don't want. Of course the best approach (always in my opinion) is to use detectors. It would be better if you could define a polygon collision region, but using some detectors is a simple way of testing regions for collisions ...

So to update you on this issue. Francois was kind enough to provide the source code for the object and I have taken a look through it to see what can be done. The rendering of the 3D mesh is achieved using Irrlicht. The version currently being used is very out of date and there is better mesh support these days, but there is some inconsistency between the mapping of actions to methods in the latest version of Irrlicht. However, Irrlicht is responsible for managing its own device context in its own abstraction layer. I have researched sharing resources between device contexts with D3D9. Apparently this was only made available in Vista and later, and it has to be created with sharing in mind. So to get this to work it would require significant rework of the Irrlicht library, perhaps pulling out the rendering code and rendering directly to the D3D9 device that MMF has created. This is very difficult to achieve, particularly for me as I am not well versed in D3D9. If this were OpenGL then it would be very easy to share data between the contexts. The most accelerated method that I can achieve currently is to layer the context in its own child window. This probably isn't an acceptable solution. I hope this at least explains why hardware acceleration for this object is non-trivial.

Matt,

Does this now add further support to the mention of utilising OpenGL in MMF3 then? I think so.

Rather than 3D Mesh with a updated Irrlicht it would probably be better to just remake it with a modern multi 3d import library like Open Asset Import Library which uses D3D9 for rendering.

From the sourceforge project page:

"Importer library to import assets from different common 3D file formats such as Collada, Blend, Obj, X, 3DS, LWO, MD5, MD2, MD3, MDL, MS3D and a lot of other formats. The data is stored in an own in-memory data-format, which can be easily processed"

Reads more than 30 3D file formats, including Collada, X, 3DS, Blend, Obj
Converts them to a hierarchical in-memory data structure
Provides 'post-processing steps' to improve the input data, i.e. generate normals and tangents or fix import issues.
Provides APIs for both C and C++
Imports skeleton animations and skinning weights
Supports complex multi-layer materials
Windows-based model viewer, the library itself is portable

The problem with using D3D9 for rendering is that I have no idea what I am interfering with. Perhpas D3D9 does offer a way of rendering something completely new without knock-on effects in a context. With OpenGL I can create a new context, render to texture and share that texture with the main context. D3D9 makes it very difficult to share data between contexts (you have to have set it all up in a way that allows you to share it) and as I mention, it's impossible in some cases.

Atom has hit the nail on the head; a self-managed rendering solution is exactly what ought to be done, however it's difficult to find and justify the time for it. I'm sure if a big pot of money suddenly appeared in support of such an extension it might get done, but it's not likely otherwise. There is a very strong argument for using OpenGL in MMF3. I'd be surprised if it didn't use OpenGL to be honest.

Having said that, it may be possible to render things using a new render target (this is actually what the 3D Mesh extension is doing). I may produce a proof of concept to show that it can be done and then maybe offer a solution. For the record, I intended to use the open asset import library in my OpenGL rendering engine, so I may be able to kill 2 birds with 1 stone with a mesh object implementation.

I swear there was an extension for this that does exactly what you need,

Example attached,
use arrow keys to rotate,
space to change animation.

Use extension viewer to grab the 3D mesh extension if you already have not.

3d meshes = go with unity or other 3d development tool, even if the game is played in a 2d plane.. its really the way to go, unity isnt too hard to learn once you get into it.. for 2d stuff though, MMF is the best! Just my 2 cents..