OGRE on PS3 and Wii

[knox_1234]

I don't know if there are similar posts already present. But I couldn't find anything relevant.

I want to know if OGRE can be extended to PS3 and Wii by writing renderers for PS3 and Wii.

The reason I'm asking is that OGRE is a wonderful library. It can used to address almost all OS for the PC and the XBOX.
But if it could be extended to the PS3 & Wii, then it would be a real winner.

I want to know if it cannot be done at all and why.
If the answer is 'yes', the how and if anyone has attempted it.

Thanks in advance.

[syd]

yes, it's possible, but besides the renderer, porting Ogre would require to port the system api also. and Ois may not work.

The problem is that the wii or Ps3 SDK, is not availlable for indies.

[jjp]

http://www.ogre3d.org/phpBB2/viewtopic. ... re+console

[knox_1234]

Assume that we get the Wii or PS3 SDK by becoming a registered developer.
I want just the rendering part of OGRE and OGRE is meant to do that. I'll handle gameloop, input, sound, nw, etc on my own.

Is is just a case of writing a new renderer for OGRE?
Will everything else fit in?

I saw in the other post that some people have tried. But I didn't any more info than that.

[nullsquared]

The problem here is that very few people have actual development access to the Wii/PS3. So it's not a "community-effort" to get a Ogre render system running on those consoles, it's usually a one-man attempt by whoever is lucky enough to have such access.

[jjp]

Assume that we get the Wii or PS3 SDK by becoming a registered developer.

The point is that you can't have an engine with an open source licence for the consoles. Even being a registered developer you would violate your agreement with Nintendo, Sony or Microsoft because the code would reveal information that isn't meant to be public.

[Kencho]

I see certain workarounds here. There's obviously the Ogre closed license, which cost a bit of money but in return you aren't forced to open any source code you write, even if you're playing with the Ogre internals. The second is that writing a RenderSystem plugin doesn't require to open source it according to the LGPL.

I don't know much about the licensing contracts of Nintendo, Sony or Microsoft, so in the end that would be a matter of contacting them and talking about these issues.

[Klaim]

Anyway one the the major issue we can guess for now is the memory management that is totally based on the default "new" statement in the current stable version of Ogre, and that will be (for the most parts at least) fixed in the next stable version.

jjp> Assuming that PS3 uses some kind of Embedded OpenGL interface and XBox360 a DX10 interface, we could assume too that the OgreMain part of Ogre could be fixed (if it's not already done) to compile on the compilers for those consoles and don't provide the specific renderer modules officially?

[Kaelic]

I'd say part of the problem is not just porting (which is probably easy) but making use of the actual technology behind the PS3. Any decent engine on the PS3 is very data driven and ready for good use of the SPUs. Just building a render system on OpenGL ES would lack the extra kick to even be worth porting it to PS3.

[Praetor]

If you have the licenses for development I'm sure it can be done. You would be writing a completely new rendersystem, but it should have the flexibility necessary to take advantage of any benefits and avoid any weaknesses on each platform. But as people have said it can't really be a community effort and we can only give so much advice since it is you and not us who would have the licenses.

[xavier]

The PS3 point is very valid, and is nearly as valid for the 360. Ogre simply is not a concurrent enough design for an easy port that actually is more than "yeah it runs on this platform". You would have to rewrite so much of Ogre to get it to perform optimally on a PS3 that you might as well skip Ogre and just write a render engine from scratch. And unless your Ogre-based game were already written to run Ogre in its own thread, communicated via message queue or some other asynchronous method, you aren't going to get the benefit of having 6 (ok, 5) cores on the 360 either. One example is animation and particles -- since these update Ogre object state data, there is no non-serialized way to update those systems in their own thread if you are using Ogre for animation (skinning as well as morph) and particles.

The Wii is less of a concern because it's already a single-threaded architecture -- however, it's also a fixed-function architecture, so you lose a significant portion of what Ogre provides in terms of the programmable pipeline. Its texture unit state management is also quirky enough that you end up rewriting most (if not all) of the fixed-function code in Ogre, so again, you might as well just write a performant layer using the Wii SDK API.

[morfiel]

Having had some (limited) insight in PS3 development I generally disagree with the opinion expressed here that there are technical reasons against porting Ogre to Cell.

Looking at the cell architecture, you have a GPU with an OpenGL-like interface, so exchanging the renderer should not be a big deal. Then you have to port all the Ogre-specific code to Cell (disregarding the SPUs) which should also be doable.

Third you have to ask the question how to make use of the SPUs. This is generally a little though because the things don't have access to main memory. On the other hand, you have to ask the same question when you build an engine from scratch and probably will come to the same conclusion. Namely, that parallelizing anything related to the main loop and rendering itself is not reasonable. So you basically have the same situation you have when writing an Ogre-App for a, say, Quad-Core CPU. And this situation will be that all the parallelism takes place in Application level, not on Ogre-Level. Granted, writing an Application for SPUs is tougher than for a Intel Quadcore or XBox360 CPU, but that problem will arise _after_ you ported Ogre and independently from the question if you are using Ogre or some different engine.

Aftertought: what good are the SPUs anyways? I wished for some SPUs when programming on a PC for:
- realtime texture synthesis
- procedural generation of geometry
- rendering of sky-textures using volume-raytracing
- I even though about on-the-fly baking of ambient occlusion maps for procedurally generated geometry (using ray-tracing again).

The list is not exhaustive, but it might give you an idea of what the SPUs can be used for.

[voxel]

And this situation will be that all the parallelism takes place in Application level, not on Ogre-Level.

The problem is that OGRE, while only being a graphics engine, still does too much at the core - animation, skinning, particles - which could be considered application level things but as xavier mentioned affect the Ogre state and are not easily separable.

i.e to add angular velocities or acceleration to particles means I have to dig into the core data structures of OGRE.

Heck, even visibility testing is an application level task to me.

[Link_of_Hyrule]

I have talked to a few Wii homebrew developers and they have said it should be easily portable to Wii because it runs on both mac and linux anyways heres some links you guys might like I hope someone is able to port it to Wii.

http://wiibrew.org/wiki/DevkitPro

http://wiibrew.org/wiki/Development_Tools

http://www.gc-linux.org/wiki/Main_Page

http://forum.wiibrew.org/read.php?19,333,333

[SiENcE]

A good starting point would be the pocketPC fork: https://ogreaddons.svn.sourceforge.net/ ... /PocketPC/

[Assaf Raman]

... The second is that writing a RenderSystem plugin doesn't require to open source it according to the LGPL....

If you do that - you will have to give out the OGRE code on your DVD if you use a DVD as the delivery method of the game.

[Link_of_Hyrule]

well if any of you are interested in helping this guy Tinte is going to try and port ogre to Wii after he experiments a little with some stuff right now he made a small 3d engine that loads textures, meshes, and lighting but thats the last i heard from him so idk whats going on right now.

[xavier]

... The second is that writing a RenderSystem plugin doesn't require to open source it according to the LGPL....

If you do that - you will have to give out the OGRE code on your DVD if you use a DVD as the delivery method of the game.

No, what you do is pay for the OUL, which is why it exists.

You can't "give out" the code on a DVD because the DVD for console titles is encrypted.

[SiENcE]

It seems that Deck13 ported (maybe not the whole ogre code) to XBox360 .

Their new Game "Venetica" uses Ogre and they want to publish it on PC and XBox360 (later for Linux and MacOSX):
http://www.golem.de/0808/61960.html

Can anyone confirm the Port?

[synaptic]

... The second is that writing a RenderSystem plugin doesn't require to open source it according to the LGPL....

If you do that - you will have to give out the OGRE code on your DVD if you use a DVD as the delivery method of the game.

No, what you do is pay for the OUL, which is why it exists.

You can't "give out" the code on a DVD because the DVD for console titles is encrypted.

i was under the impression that you didnt need to distribute the code on the medium it's released on, only that the code is made avaliable.. such as on a website, we covered this in my first year at uni, so my memory is a big vague now..

[Azgur]

i was under the impression that you didnt need to distribute the code on the medium it's released on, only that the code is made avaliable.. such as on a website, we covered this in my first year at uni, so my memory is a big vague now..

I also believe this is the case.
I recall hearing something very similar while sorting out licensing issues.

[xavier]

It seems that Deck13 ported (maybe not the whole ogre code) to XBox360 .

Their new Game "Venetica" uses Ogre and they want to publish it on PC and XBox360 (later for Linux and MacOSX):
http://www.golem.de/0808/61960.html

Can anyone confirm the Port?

Given that the topic is about PS3 and Wii, I can't see how this is relevant -- 360 uses DirectX and porting the DX rendersystem to the 360 is actually about a two-day task (including debugging time).

The issue is that there is no "porting" to the Wii or PS3 -- it's a ground-up new implementation, and unfortunately, Ogre (like most software) is not designed suitably well for use on the PS3 Cell architecture.

The Wii is probably slightly more suitable, but it's also 100% fixed function (and not PC-graphics fixed function either), so there is no real porting there either -- ground-up again.

[Assaf Raman]

It seems that Deck13 ported (maybe not the whole ogre code) to XBox360 .

Their new Game "Venetica" uses Ogre and they want to publish it on PC and XBox360 (later for Linux and MacOSX):
http://www.golem.de/0808/61960.html

Can anyone confirm the Port?

Given that the topic is about PS3 and Wii, I can't see how this is relevant -- 360 uses DirectX and porting the DX rendersystem to the 360 is actually about a two-day task (including debugging time).

The issue is that there is no "porting" to the Wii or PS3 -- it's a ground-up new implementation, and unfortunately, Ogre (like most software) is not designed suitably well for use on the PS3 Cell architecture.

The Wii is probably slightly more suitable, but it's also 100% fixed function (and not PC-graphics fixed function either), so there is no real porting there either -- ground-up again.

Does the the 360 have fixed func or only shaders?

[SiENcE]

It seems that Deck13 ported (maybe not the whole ogre code) to XBox360 .

Their new Game "Venetica" uses Ogre and they want to publish it on PC and XBox360 (later for Linux and MacOSX):
http://www.golem.de/0808/61960.html

Can anyone confirm the Port?

Given that the topic is about PS3 and Wii, I can't see how this is relevant -- 360 uses DirectX and porting the DX rendersystem to the 360 is actually about a two-day task (including debugging time).

@xavier: I thought the discussion turned into ... "If you do that - you will have to give out the OGRE code on your DVD if you use a DVD as the delivery method of the game." ... discussion. And this was my point.

[Kojack]

One of the problems with lgpl on a console is that one of the primary goals of lgpl is to allow the user to replace an lgpl component of a program with a modified copy. So if a console game used Ogre under the lgpl instead of the OUL, it doesn't matter if the console specific stuff is kept in a binary only non lgpl render plugin, the end user still needs the ability to recompile a modified version of ogre and either drop the dll into the game's directory (kind of tricky) or relink with the entire game object files or source. Either way the end user needs to compile ogre for the console (so you need the console's toolchain) and some how get the game to accept the new version (copy protection and encrypted hddvd/bluray discs make it hard).


Section 4 of the LGPL:

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:

* a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.
* b) Accompany the Combined Work with a copy of the GNU GPL and this license document.
* c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.
* d) Do one of the following:
o 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
o 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.