Introducing: PlasmaClient!

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

MercAngel wrote:

something i was playing with a bit ago before the max plugin and some other stuff do not know if you can get any thing out of it but have a look alos think is has some plugin for blender also

Crystal Space is a mature, full-featured software development kit (SDK) providing real-time 3D graphics for applications such as games and virtual reality. It is free (LGPL) and cross-platform (Windows, GNU/Linux, Mac OS X).

I toyed with the thought of using an existing rendering engine, but the way Plasma materials and textures are setup, that would be just about as hard as writing from scratch - all the flags would have to be parsed anyway, and converted to the new engine format (as opposed to just setting the graphics state directly) - and of course the Plasma flags may interact differently than similar flags would in the other engine. This way I can make sure my renderer draws scenes the same way CyanPlasma does.

In other words: Using an existing rendering engine would end up with much of the same coding work (converting flags from one format to another, mostly) with a drawback of possible differences in functionality introduced by code I don't control.

JWPlatt · **Posted:** Thu Sep 23, 2010 3:13 am

Besides my other idea of supporting peer to peer ad hoc sessions, I'd like to see this released as an SDK with a dll that the (small) client uses, Then it can be better used out of the box as a general Plasma render engine for other things. A specific example might be calling a flyover cutscene with realtime rendering from a .NET application.

Paradox · **Posted:** Thu Sep 23, 2010 3:22 am

You realise that libHSPlasma has been open-source and publicly available since 2006, right?

It's also the library used by the Plasma/Prp/Vault Shop tools, PyPRP2, branan's MoulFixer, prpl-uruki, and a handful of other projects.

It's like a Plasma SDK, but with support for multiple versions of Plasma

JWPlatt · **Posted:** Thu Sep 23, 2010 4:25 am

Ok, fair enough. Then I have some questions about the SDK that were going to wait until much later:

Is it legal?
Is there a dll?
Can I make a .NET reference to the dll?
Can I legally call the dll from a proprietary commercial application?
Are the the dll and associated documentation easily found for download?
Does the SDK documentation have all the usual class, method and enumeration descriptions in a nice format?
Can I call the dll to render a flyover in a resizable window under .NET?

Though it should be a given that if this is a new application, I (as a typical new product developer) don't much care about backward Plasma compatibility that is only there to support legacy Cyan content. i.e. Nice to have for fans and hobbyists, but not too important going forward for a generalized engine. That's not to say you won't have to have backward compatibility for everything new going forward - you will. I'm just saying legacy Plasma support won't much matter to new things.

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

That website should answer all the questions you have - it says what language it's coded in, what the license is, and has various download formats available. The only unanswered question is legality, which with any project is iffy anyway, because of the huge number of silly ways to break IP laws. We the developers feel we're in the clear on that front, and several projects using it being discussed on this very forum show at least a tacit acceptance by Cyan.

Can I have my thread back now? pretty please?

Pavitra · **Joined:** Sun Feb 14, 2010 7:53 pm **Posts:** 157

JWPlatt wrote:

Though it should be a given that if this is a new application, I (as a typical new product developer) don't much care about backward Plasma compatibility that is only there to support legacy Cyan content. i.e. Nice to have for fans and hobbyists, but not too important going forward for a generalized engine. That's not to say you won't have to have backward compatibility for everything new going forward - you will. I'm just saying legacy Plasma support won't much matter to new things.

There are already plenty of generalized engines for 3D MMOs. I don't want a generic engine. I want an engine I can call Uru.

JWPlatt · **Posted:** Thu Sep 23, 2010 5:05 am

Pavitra wrote:

There are already plenty of generalized engines for 3D MMOs. I don't want a generic engine. I want an engine I can call Uru.

Understood. The more new products this PlasmaClient - this viewer - can render, the better off our Uru will be as Plasma broadens its success.

Paradox · **Posted:** Thu Sep 23, 2010 5:13 am

Our goal isn't to make a new Plasma, but to make an open-source implementation of the existing Plasma, fully compatible with the existing content.

libHSPlasma is intended primarily as an IO library for reading the content files and parsing the data into object classes. It is not an engine itself, nor does it aim to be.

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

Right. libHSPlasma is a library to access PRPs, Plasma fonts, SDL files, etc. It also has some networking functionality (which is what, for example prpl-uruki moulfixer use to do their dirty work). It's designed in such a way that an application built on top of it can add functionality to those purely IO classes.

PlasmaClient uses that capability to add functionality matching (or exceeding) Cyan's, in order to be a compatible with Cyan's datafiles (and in theory servers, but as I've said before, networking is limited to "get startup working"). I have no interest in breaking this compatibility, though I do plan to add additional functionality as I can.

Unfortunately, the implementation here means PlasmaClient's classes are tied pretty tightly to the engine. Cyan avoids this by passing messages everywhere, so if a particular manager isn't in a particular build, it's no big deal. PlasmaClient uses direct access to those manager classes whenever possible, so splitting off the code into a more complete library isn't going to happen anytime soon. My way is, however, much more efficient - that's the sort of tradeoff you have to look at when designing these things.

libHSPlasma and PlasmaClient are both GPL, so you're welcome to make a new project and borrow whatever bits of classes and implementations you need for your project, create bindings to new languages (libHSPlasma has python bindings already, for example), or even fork them and add, change, or remove functionality in your fork... as long as you share your code too. I don't think that's too much to ask given how much effort we've all put in to libHSPlasma, PlasmaClient, and the other public tools and utilities.

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

Moving back to the original topic of this thread: I've just sent OHB a draft of new page text, hopefully we can finally get this "better website" ball rolling

Regnad Kcin01 · **Joined:** Mon Apr 26, 2010 5:37 pm **Posts:** 58

Hello Paladin,

A couple of suggestions.

First, if you plan to update the website with screen caps in order to visually demonstrate your progress, it would be more valuable if you create new screen shots from the same location and viewpoint as previous screenshots. Establish a half dozen benchmark locations for screen caps and use them every time.

Second, change the background color of your website to black, or at least a neutral gray with RGB values of 100 or less, especially on the home page where the smaller thumbs reside. Properly evaluating subtle rendering changes is impossible with the current website.

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

Right now the screenshots aren't intended so much to show progress as a "look what's working right now!" sort of marketing thing. I'll definitely consider showing some shots of the same areas as things improve a bit more... Right now I think it's still a bit too work-in-progress to be worth really showing off.

Also, you can click through on the pictures to get life-size versions of them. The background color there is entirely dependant on your web browser, though you can certainly save the full-size pictures to your computer and view them in a more reasonable program.

As for website colors... New website stuff is in the works, I'll look at theming stuff when I have a bit more of a handle on what the site architecture is going to be.

KT · **Posted:** Mon Sep 27, 2010 1:49 am

I wish I could help, but my computer skills are below that of a very slow hippo...

MustardJeep · **Posted:** Mon Sep 27, 2010 8:21 pm

Paladin I applaud your new client.

The screen shots look pretty good for PR test runs. Just wanted to ask however why bullet physics?

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

MustardJeep wrote:

Paladin I applaud your new client.

The screen shots look pretty good for PR test runs. Just wanted to ask however why bullet physics?

Because of the open-source license I'm using for PlasmaClient, I'm pretty much restricted to Bullet or ODE. Cyan tried using ODE in Plasma for Myst 5 and had a lot of trouble with it, so rather than going down that road again, I decided on Bullet.

EDIT: I could add license exceptions to link against a given physics engine, but then there would possibly be issues with other people using my source wanting to use those engines... its safer to say all the commercial-licensed engines are off the table

EDIT2: I know there are other open-source physics engines, but Bullet and ODE are the two most mature and well-developed.

Introducing: PlasmaClient!

Who is online