Question: How many Tri's (roughly) can maratis handle? (Page 1 of 2)

There is no theoretical limits, it depend a lot what platform you target and the rendering you want to use,
for an iPhone for example you should try to have less than 5000 triangles visible at the same time.

For a recent computer, I would say less than 100 000 visible at the same time if you are using baked shadows, and if you are using dynamic lightning and shadow map, try to reduce the polygon count. It will depend a lot on your 3d card.

Most important is to try to subdivide your environment.

I thought I would try pushing Maratis to see how far it could go. I tried loading a high poly model one of my colleagues is working on, currently at 486k tris. Using the 3DSMax exporter it made a 159MB .mesh file. That didn't load. I think it gave up part way through or something. We exported it as .obj and then took it through blender which made a 50MB .mesh file which loaded perfectly. It didn't take long to load and definitely didn't have any problem rendering almost 500k tris. Much as I'm sure some other engines are more optimised, Maratis seems to hold up pretty well.

I will do a couple more tests, throwing as many polys as I can, along with textures, animation and shader work and see if I can get any GPU bottleneck for rendering at all.

Artist's CG Talk thread

EDIT: I wouldn't suggest that 500k tris is an acceptable amount for an in game character model, I was just pointing out that Maratis seems to hold up pretty well

Last edited by Nistur (2012-01-16 20:27:40)

I'm not sure if there's a difference between unity pro and free, but I know some people who have pro licenses. I can have a go at getting a scene in both at some point and try to give you some metrics

So, I've started having a play around with Unity. Apart from the fact that it has more features than Maratis, I don't think that it's that much better. I haven't got any numbers yet to back up the performance, but the development experience seems to be pretty awkward. I asked one of my colleagues to help me with the interface because very little made sense to me at first glance. I guess with a couple of tutorials I would get into the Unity mindset and things would make sense. Maratis, on the other hand, I didn't need a tutorial, was nice and simple

Ok, so I did build a standalone .exe for Unity but I haven't been able to get the mech model from Umar yet, so I removed the model from my Maratis test too.
Unity runs at ~5% CPU with ~17MB memory.
Maratis runs at ~49% CPU with ~71MB memory.

When I added the model to Maratis, the CPU usage went up to 95% and the memory to 103MB. As soon as I can get the model into unity, I will be able to see whether the model has significantly more overhead than in Unity, but as it stands, it's clear that something's working harder than it needs to. All I have is 1 light, a box (/plane) with box collision and the standard Sponza controller.

Still, I don't think it's that bad a result for Maratis. Unity has millions of dollars poured into it's development and has been optimised a lot *shrug*

EDIT: This PC Is an AMD Phenom II X2 550 @ 3.1GHz with only 2 cores unlocked

EDIT EDIT: Unity doesn't seem to want to load the mech model, whatever format we give it, obj, fbx, whatever... Oh well, I'd best get back to work

Last edited by Nistur (2012-01-24 14:25:00)

It wasn't an entirely empty scene, it was the box.mesh stretched into a floor with SponzaFPS mouse control script and 2 lights.

If there's any more testing you would like me to do, I can try and throw similar things at Unity. I'm also still chasing up some things about the PSP work, so if I can't get that to finish up, I might try and do a bit of code profiling, see if I can work out where the memory is hiding and what's taking so many CPU cycles.

I seem to remember that, if you let a process just run on, it will eat up as much CPU power as it can (in this case 49% makes sense as it's almost all of one core...) what you usually have to do is stick a sleep() at the end of the loop. I haven't checked if Maratis does this yet, but it's potentially what might cause the phantom CPU usage.

I was using the latest svn version without any modifications, built with scons.

if you put sleep(10); at the end of the loop, the thread will sleep for 10ms. It won't have any effect at all (until you're really pushing the CPU) apart from just letting the OS know that you're not actually using so much power. Still wouldn't explain why the model suddenly made the CPU shoot up so much, but then again, I guess ~500k tris probably has something to do with that.

With regards to the memory usage, like I said, I'm not getting much done with the PSP stuff right now, so I may as well put that on hold for now. I've done some memory management at work, so if you want, I can try to take a quick look at that. Might be interesting to make a profiler plugin for Maratis actually

I have checked that there is nothing apart from the box.mesh in the meshs/ directory. I have no idea what's happening :S

There are some tools on various platforms that will allow you to do CPU/memory profiling, but very few are cross platform and will allow for Maratis users to optimise their games properly. Not sure if that's important to you. What I was thinking is that we can add a MProfilerContext to MEngine, and then create macros to do something like the following:

#define M_FUNCTION_PROFILE() \
MProfileStack func(__FILE__, __FUNCTION__);

Which will wrap up checking if there's a profile plugin attached and will release at the end of the scope. I actually had a look at profilers before and Shiny Profiler looks nice and simple to make into a plugin

With regards to memory management, it would probably be a bit more hassle as it means overriding new/delete globally so you can keep track of the memory yourself. Not as painful as my fopen hack as C/C++ will allow overriding them but that can tie into the MProfileStack again, then you can print out the memory as it's been saved, with the file and function it was allocated in. Of course you don't want to have either of these things running in a production build, but if they're wrapped in a plugin, will allow projects to test what's happening, and the MProfileStack class should take minimal overhead if there's no profiler. Can even create a FinalRelease player build which defines M_FUNCTION_PROFILE in the build process, so it's not even implemented.

EDIT: I had a quick look at memory profiling, and found this which basically explains what I mean, but if we have the MProfileStack, we can actually point out when and where the allocation came from

Last edited by Nistur (2012-01-24 16:27:59)

I will try and do some benchmark tests with the mech mesh and svn revisions, unless you have an archive of previous builds I can use.

If there's anything more detailed you want, I can quickly plug in either memory or CPU profilers I recommended within a matter of hours to get a quick reading on what sort of things are heaviest. I was just suggesting wrapping it up nicely so it could be used by others in future.

I'll send myself the mech mesh and do some tests at home. I wasn't using any profiler to get the numbers, I just glanced at windows task manager.

It's unfortunate that I can't seem to load the mech into unity, no matter how hard I try

you was right for the sleep, it put the cpu usage down.

strange... is it on windows ? windows 7 ? (I only have xp)
on macosx, there is something called inactive memory, when debugging memory xcode show that the memoy used is 32mb, but the monitor shows 100mb (active+inactive). Is it like that with win 7 ?

Just found on the net, someone using Maratis as a renderer :

Nistur edit: update image URL as original one expired