The website already answers most of the questions as the_clown said, but I'll answer them here again in a bit more detail and the reasoning behind it!


Out of the box there is support for our own file format which can load models pretty much as fast as your hard drive can funnel them into RAM. But that is as much fun as having to convert everything to MDL, so there is also an assimp module that provides support for common file formats such as .x, .dae, .obj and fun like that (fun fact: Did you know that the reed model in the instancing test scene is an MDL5 model?)

Besides of that, you can theoretically support any file format that you want, provided that you write a resource loader for it. The ResourceCoordinator and ResourceLoader classes provide functionality to add support for custom file formats, which seamlessly work in Rayne (ie you can simply ask Rayne for an RN::Model instance of your custom model and the resource coordinator and your loader will do the rest)



I don't know of such a tool either. You are talking about things like the F.E.A.R. AI where they added informations for the AI into the animation, right? That's not supported out of the box, mostly because there is no generic way of adding such informations. In theory, again, you could simply go about subclassing the RN::Animation class to additionally hold the information you want and then provide a custom loader for your own animation format that provides these informations.

That's not going to be much fun though I'm afraid, especially since it requires you to roll your own animation format. An alternative might be enforcing a naming scheme for your keyframe animations, which is something you can do with Rayne: It allows you to extract frames of an animation into a newly named set (in case the animation is just flat or provides wrong frames... Hey Arteria!). How much information you can store in them is a different thing though.



http://rayne3d.com/community


No. The engine core will be closed source. We do provide you with release and debug binaries and additionally debug symbols, but that's going to be it. The biggest issue is not so much that we cook some super secret IP stuff that no one is allowed to know, but because it's a nightmare in terms of licensing. The only option would go with dual licensing, GPL and our current license, but what would be the use of that? You either get to hack on Rayne but everything you use it for must also be GPL'ed, or you don't get to hack on Rayne and instead have more or less useless source code.
And we don't want open source coders to work on a GPL'ed Rayne and then have to merge their changes back to us upstream so we can go ahead and sell their code.

Furthermore: Rayne is designed to be extensible out of the box. So you can already add functionality and replace things, without having to hack on the engine core itself. If you don't like the scene manager for example, no one is going to stop you from rolling your own (and you only have to create a custom scene manager, not re-invent the wheel because the engine doesn't like being changed)



Sure thing! You have access to the high level thread class and synchronization primitives, as well as the thread pool which does an awesome amount of work on your behalf to get your code running on all available CPU cores.


Aaand now... How about some more editor screenshots?

(Duplication of scene nodes foobar etc. pp. to make fence building easy)

And now for two screenshots of a moving sun:



The Sun class is something that Rayne doesn't know about. It's part of the test game, but Rayne provides a KVO and KVC system to export and observe properties of objects, which is something the editor makes use of. Note the "Time" property in the inspector, which is a property exported by the "TG::Sun" class.