Thinking of Switching to Ogre...

[Telamon]

Hey there guys,

I'm a long-time lurker, very occassional poster. I work at a small software startup called Roblox. We're making an online virtual world set in a world made of generic non-branded plastic building blocks.

We're trying to gain control of our graphics pipeline. Right now we are using a custom fork of G3D that a contractor made for us 12 months ago. Since then we have not touched the graphics code much at all, but I really want to get into it and start shaking things up. In the future we want things like animated meshes, particle systems, CEGUI support(!) and all the cool things that Ogre would give us for free. The problem is that our game has some pretty specialized rendering requirements. Specifically, our game has no static geometry. Bricks need to be able to be blown up, fly across the map, be snapped together, dragged around, ect ect at any time. We've done some pipeline contortions to make this fast even on a PIII 700 Mhz laptop with integrated graphics. Is there any chance Ogre might still suit our needs? I've only done one small Ogre project back in 2004 and I remember back then you needed to bake your static geometry to get good performance (or I was too big of a noob to figure out the Right Way to do things back then).

Anyways, if someone with experience could evaluate how much sense a switch to Ogre makes for us, I would be very greatful.

We have an online alpha test up on our website (needs IE, sorry). Maybe some screenshots will entice someone to try it out and write an assessment. Or if you don't want to DL anything, check out the google video trailer.

[Frenetic]

our website (needs IE, sorry).

Seems to work fine on Opera 9.

[edit] Unless you mean the game runs in the browser using an ActiveX control.

[CaseyB]

Nope you need to download a client, but it ran really horribly on my 'puter. It locked everything up and I had to kill it.

[Telamon]

I forgot to hammer this point above - right now we can run on 5-year old hardware and no graphics card. If we switch to Ogre, can we still expect that to be the case?

---

Frenetic:

Well I know the CSS is all messed up on Firefox. And yes, we do use ActiveX, at least until something better comes along.

[Telamon]

CaseyB: I would be curious to know your system specs - especially your graphics chipset, if you would be so kind? Sorry it didn't work for you.

[CaseyB]

AMD 64 3500+ 2.21 GHz, 512MB RAM
Nvidia GeForce 6600 128MB

[Zeal]

I see no reason why you couldnt do all that and more with Ogre. You could even use some advanced techniques like instancing if you really want to have lots of little moveable objects and still maintain a high framerate (although I think you could get away with simple entities just fine).

I switched to Ogre a few months ago, and would NEVER go back to my old graphics engine. In fact, I dont want to ever use ANY closed source, single platform engine ever again.

[CaseyB]

There was also someone on here just last week talking about creating a Voxel based scene manager. You may be able to leverage his ideas.

[Evak]

how many seperate bricks are you thinking of using. Were making a cad tool and later a game that uses patented blocks.



Without any special optimization we can manage about 6000 blocks quite happily so long as we don't have shadows on. Were redoing some of our toolset and will probably make another effort at optimizing when Eihort comes out.

For us the rendering of so many seperate cloned meshes with snapping helper nodes slows everything down considerably so I'd be interested to see what solutions you come up with. Our blocks probably have more triangles than yours because they conform to some engineering plans where the blocks and clips that hold them together must fit in a partciular way.

I'm going to have to grab your demo when I next get the chance and see what you have done

[Zeal]

Wow 6000 unique entities? You should check out the summer of code project about instancing. Im sure that would help a LOT.

[Vectrex]

Also keep an eye on the LiSPM shadowmap shadow work, that would be WAY faster than using stencil shadows for something like this.
I'm also interested in how you got so many entities running.

[sinbad]

Hey, I saw a post for Roblox a little while back (on GameDev I think) and loved the look of it. We'd be very happy if you switched to Ogre

On the hardware front, it depends. Ogre has Dx9 and GL renderers at the moment, there was a Dx7 renderer but it was dropped due to lack of interest. Personally I haven't seen any cards that Ogre flat won't run on, although if you're using more advanced features some of the later Intel embedded cards can be a challenge (mostly because they totally lie about their hardware features, claiming high pixel shader support but actually emulating it in software, the cads). GL drivers tend to be dodgy for anything non-nVidia/ATI so D3D9 is probably the best target. If you're using fixed function I don't think you'll have any problems, but if you find a machine we don't run on, send us details and we'll try to figure out why. Ogre has been around for long enough that we've covered most cards at some point or other, but we don't have a big pile of them lying around to retest all the time. Well, not a huge pile anyway (I have about 6 ).

If it's browser rendering you want, you might want to look at Emma or Blink3D, both of which use Ogre to render in a browser.

On the 'lots of blocks' front, the limiter here is driver time. Every batch (that is, every set of geometry which has a separate world transform or a separate material state) has to go through the driver, and this runs on the CPU. Therefore how many separate batches you can render is a function of how fast the CPU is rather than the GPU (hence why we encourage good batching through StaticGeometry, instancing or some other method). I'm betting that Evak has quite a fast CPU which is why 6000 separate objects isn't a problem. As a rough estimate, a 1Ghz machine can deal with about 25,000 batches per second if it's doing nothing else - so assuming a 30fps target that's no more than 800ish batches per frame. Clearly you'll probably want to batch things up to get lots of objects running on low-end CPUs, and grouping together currently static objects is a very good idea. See http://download.nvidia.com/developer/pr ... zation.pdf for more details on the general cause (this is far from an Ogre issue).

The thing is, some older software engines did this batching anyway because they send all their geometry to the GPU every frame (OGRE doesn't, it keeps it on the card in accordance with modern practice),so older engines can often perform better on older hardware. But, they won't scale to modern hardware with high poly counts like OGRE will.

[zeroskill]

It's true, lack of batching will kill your performance. Even something as seemingly pointless as performing your own batch combining before you send them out the door to the card will net you some FPS. (I did this to the OpenGUI renderer a while back and it nearly doubled the FPS.)

1 batch per object (or in my case, 1 batch per quad) is an effective way of making your application crawl.

Given the block construction style of your application, I would imagine that some form of level processing could seriously reduce the batch count by simply grouping blocks together using a brisk Octree grouping algorithm. Group them together, put them into a "sleep" state by throwing them into a static geometry, and then wake them up only when you need to make changes to them. The whole process should be pretty painless and would definitely be worth the effort.

[Telamon]

We can support single player worlds with about 40,000 bricks right now on a decent card. Networking is the bottleneck at the moment, but this will not always be the case.

We are shooting for worlds containing a million bricks, with various LOD techniques to make this fluid at all times, regardless of what is going on in the simulation, or the constraints of the platform we are running on.

Right now we do some clever things to reduce our render state changes to almost zero for every frame. I don't know enough about the Ogre internals to judge whether we could get similar efficiency with Ogre.

Is it possible to manage index and vertex buffers ourselves within Ogre? How much overhead does instancing or grouping primitives into static geoms add? I suspect instancing will not help us since we allow arbitrary brick sizes.

How derelict is the DX7 renderer? I <3 software rasterizers.

[zeroskill]

Since you are effectively dealing with world geometry, it would be best implemented by writing a custom SceneManager. Once you've decided to do everything in a SceneManager, you pretty much have full control over all of the various aspects of rendering the world. You basically just create your vertex/index buffers, generate render operations, and throw them into a render queue for drawing. During the render queue filling you can create new vertex and index buffers at your discretion, or reuse previous ones if desired. In general, the HardwareBuffer classes provide quite a bit of control, so I doubt you'll run into much of an issue there.

Using StaticGeometry is a bit of a hack, and only works well if you are looking for a quick-n-dirty way to condense mass amounts of random entities into bigger chunks for batching purposes. The ideal solution for you is probably to just write your own SceneManager. That should give you more than enough control over the various aspects of the rendering pipeline.

I haven't tried instancing yet, so I can't comment on that.

DX7 has been dropped for an entire version now, so basically everything that changed from Azathoth through Dagon on up to Eihort has never been applied to it. Looking at the changelogs for Dagon and Eihort should give you an idea of the things that have changed, and some diff'ing of the DX9 RenderSystem from Azathoth to Dagon and Eihort should provide enough information on what it would take to update it. RenderSystems don't seem to change much from my perspective (as an API user), but your mileage may vary once you start actually digging into the code.

BTW: Awesome screenshot. I like the idea of the Lego'ish style brick construction. Very cool concept, and obviously one that allows for very destructible worlds.

[Chris Jones]

looks great

i enjoyed playing BlockLand alot, but this looks even better and by the videos, runs faster

Good luck!

[jacmoe]

I like the idea of the Lego'ish style brick construction.

Let's hope that LEGO does too.
Looks like you've copied it in earnest, down to the red logo on your Roblox man.

[Evak]

Yeah the closeness to lego could be a big problem, allthough changing the knobly bits to squares or something would probably help .

I actually worked on a commercial lego game once and they were pretty fanatical on colours and accuracy to the point that we had colour charts with pantone colours for each brick colour they used and they even made custom bricks in cases where we wanted to do something not avaliable in the then current range.

So they take how their bricks look very carefully and would probably be pretty tough on anything that resembles them too closely.

[Kojack]

I've now got such an urge to write a lego bump shader... if I didn't have so much other stuff to do.


Lego like to bring lawsuits against anything looking similar. Look on google, there's a bunch of them.

[billrobertson42]

Just a thought...

Have you considered dynamically combining some of the block meshes at run time into manageable numbers of individual meshes, and then you can get away with having lots of "blocks." You would need some internal representation of what the chunks were originally composed of so they could be busted apart as per your requirements.

It would take some work, but once you got there, I think you would be able to get astounding numbers of blocks in the game.

Good luck

[zeroskill]

This is analogous to the StaticGeometry suggestion from earlier. If you were going to go this route, StaticGeometry would perform better because they are pre-transformed into world space. Clumping individual blocks into super-meshes is nice, but also skipping the spacial transforms is even better.

[billrobertson42]

Thanks for explaining that.

[Evak]

For the 6000 block app with seperate dynamic blocks, the slowest system I have been running it on was a 2ghz centrino with ATI X300 and it runs fine in both the abocve perspective and in the first person.

[Code309]

I just played Roboblox! You could do a lot with it if you used OGRE I think. By the way that is the most addicting game I have ever played! Two thumbs WAY up!

[Assaf Raman]

I just played Roboblox! You could do a lot with it if you used OGRE I think. By the way that is the most addicting game I have ever played! Two thumbs WAY up!

I just played Roboblox. A really nice idea.