I was just wondering if anybody knows what physics engine OSMO (or whatever you want to call it) will be running on. From what I've read, URU originally ran on top of the Havok physics engine, and then MOUL used PhysX, but it looks like all the more recent Cyan projects have been using ODE (Such as Myst V and Hex Isle). I'm hoping that the open source version of Myst Online will also be using ODE, as it is open source so we would be able to mess around with the physics engine and hopefully decrease the lag issues that seamed to arise in all previous incarnations of URU Live (which from my understanding came primarily from the physics engine).

On a related note, what proprietary libraries will we need to have to compile the client and server? I'm really hoping that everything is GPL/LGPL so that people will be able to build binaries even if they don't have Visual Studio, or whatever other proprietary libraries you can think of (Visual Studio just comes to mind because I had issues earlier today with trying to compile source on a machine which didn't have the MFC libraries). If nobody knows at this point, that's fine (if not to be expected), but I hadn't seen anybody ask yet so I figured I would. Any insight or information would be greatly appreciated.

OSMO will use PhysX.

The Plasma engines that used ODE were in the MystV branch.

OSMO will be like MOUL just before it died. There's no way Cyan with so few people can implement a new Physics engine into MOUL before they give us the code.

Also, mostly physics engines are very streamlined in themselves. The real performance issues come from a bad implementation into a game engine. I highly doubt that we could "fix" ODE to make Plasma run better.

Some proprietary libraries that pop to mind are: DirectX, PhysX, Bink.

The DirectX SDK is a problem if trying to compile on anything other than Windows.
PhysX has free SDKs for Linux and Windows
Bink's SDK costs: $6000 US but runs on everything under the sun.

So, with those libs combined they've just eliminated legally compiling Plasma for anyone other than rich Windows users.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

In that case, will the compiled plasma engine be available on the data servers in the same way that the age data will be? Also I was never implying we could fix ODE (as ODE is overall very well written code), simply that because it is open source it would be easier to implement in a more optimal manner since the underlying code is readily available, and that any minor changes that we would want to make would be much simpler to do.

I suppose it would be theoretically possible to port the plasma engine to run on OpenGL, ODE, and some less proprietary multimedia codec, but it would take a while (and someone more proficient at C than myself).

Well thanks for the info, and out of curiosity, how do you know so much about the source code?

Quote:

In that case, will the compiled plasma engine be available on the data servers in the same way that the age data will be?

I think it will be in the code repository.

I was assuming that the code will be available, but if it requires bink to compile, normal people will never be able to compile the Plasma libraries. Thus, I assume that the pre-compiled libraries will also be made available from cyan.

I think the only thing Bink is used for is the intro movies, so couldn't they just be converted to a free alternative?

_________________
Can you withstand the gaze of the Eye of Eternity?

Bink is also used for certain ingame features, such as plLayerBink, which is for displaying bink videos as textures on ingame surfaces. (such as the linking panels in myst5) While this was only used by Cyan in myst5, the feature is present and usable in ABM through MOUL. (it's been tried in PotS, and worked)

_________________
Live KI: 34914 The Story So Far
Again KI: 23247

The plus side is the generic bink toolset is free to anyone. Bad side is the actual SDK is restricted.

I think the point is there though.. it might be worthwhile in the future to consider moving it off. Can Cyan transfer the rights to using the Bink SDK to us by giving us source? Or do we just have to use the Cyan-done dll and add other ways to do anything we need to extend it with?


I think though DirectX will be the first major concern to free ourselves with, considering the wish is to get native mac/linux ports

_________________
You know, I wish we would learn Atrus loved the 1812 overture, and in turn we had a copy for our relto.
That's right, a canon canen cannon!

MOULa KI: #00027582
Welcome back all!

Gondar wrote:

I think though DirectX will be the first major concern to free ourselves with, considering the wish is to get native mac/linux ports

I thought MOUL used SDL... It's certainly there in the credits.

If that's true, then it'll be very easy to port (As SDL is available for pretty much every platform now).

_________________
Avatar: Anaerin
Ki: 118686

SDL access 3D hardware either through OpenGL or DirectX. My guess is that URU uses the later, in which case it would still be possible to port the source to OpenGL and make a native mac/linux build, but it would require a good deal of effort (might not actually be that difficult depending on how they implemented DirectX). Going from bink to h264 and mp3 or something would not be quite as difficult, but would again require a bit of work (and re-encoding of the video files from source, which from my understanding cyan will not be releasing).

MOUL doesn't seem to use SDL. At least MOUL doesn't contain the dlls required for SDL. I've been using SDL for my applications and from experience you usually have SDL.dll. It *might* be possible to implement it in without linking (having everything compiled in) but I've never seen it done. Also, if it used SDL you'd probably see stuff like SDLMixer.dll.

There is however a Plasma file type named "sdl"--State Description Language--which has nothing whatsoever to do with Simple DirectMedia Layer.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

I have made projects with the SDL libraries embedded in the binary instead of in seperate dlls, but never in a case such as URU. Normally the only reason to do so is if you are attempting to have a single binary file be the entirety of your application, with no external data files or libraries, which is definitely not the case for URU. The SDL directory in UCC has nothing to do with Simple DirectMedia Layer, but instead with the SDL file type (which I am actually inclined to believe are Alias Wavefront Scene Description Language files based on the header 0x77686174646f796f757365656d010000 or whatdoyouseem, but I'm not sure as I could find any file type details).

DRayX wrote:

I have made projects with the SDL libraries embedded in the binary instead of in seperate dlls, but never in a case such as URU. Normally the only reason to do so is if you are attempting to have a single binary file be the entirety of your application, with no external data files or libraries, which is definitely not the case for URU. The SDL directory in UCC has nothing to do with Simple DirectMedia Layer, but instead with the SDL file type (which I am actually inclined to believe are Alias Wavefront Scene Description Language files based on the header 0x77686174646f796f757365656d010000 or whatdoyouseem, but I'm not sure as I could find any file type details).

SDL files contains information about object states. SDL stands for State Description Language. These do not contain any 3D data, and are plain-text files when decrypted.

Concerning SDL (as in Simple DirectMedia Layer): the Mac version of MOUL does indeed use SDL, as part of Cider.

(It even includes a bug introduced (and subsequently fixed) by me )

Aha! The mystery credits are solved.

_________________
Can you withstand the gaze of the Eye of Eternity?