Guild of Writers

I agree with the 'doing things the blender way' philosophy, although sometimes it can lead to added difficulties. like not being able to preview in real time the exact results that you'll get in Plasma. But as more and more features (and more and more complexity) are added to PyPRP that's something we probably can't avoid in the long run. Beside, I'm pretty sure what the Cyan guys look at in 3dsMax is quite different too than what is eventually look like in Plasma..

I still think going with the page per scene system is a good solution. It's not very complex, and it's not like all Ages will require to use several pages or PRPs.. (animations and GUIs not withstanding) The visibility problem is indeed an issue, but the more I think of it the more I realize it's not something that will be that troublesome. The linked objects solution works, and although you'll need to delete duplicated objects it's not that big an issue.. Plus again, I'm pretty sure more than half of the Ages will not need several pages; I'm looking at the Ages I have downloaded and that's certainly the case. And those who do use several pages don't really need to anyway.

it would be pretty easy to create a script that makes a temporary scene with all objects in other scenes linked to it (and rig it so that it wouldn't be exported). It would be a snapshot moment though, as adding new objects to other scenes wouldn't be reflected in it until the script was run again.
You can then get rid of that scene by just removing it.

That looks like an interesting solution. I understand why some people might all this needlesly complicated, but again most Ages won't need all this..

Also I agree with the idea of keeping the 'page_num' property legacy to overwride the scenes system; this way people can use whatever method they prefer. (as long it's not a source of export issues or bugs)

Trylon wrote:But then the other question would be:
For what do we use prp's?

e.g. - in the case of the kadish alternate vault, there is one prp which has the normal surroundings, and another one that has the alternate surroundings....
Depending on the situation, either one is shown.

They are both shown at the same time but at different coordinates. If you are saying what I think you are saying a better example would be the dry/rainy cleft toggle.

just a silly question here, but is all the rendering questions and comments based on blender rendering engine or Yafray. I noticed that when I render with blender internal everything is bright(too bright) and when I render with yafray its dark untill I put in a sun lamp then it just needs adjustments.

was just wondering

Cyan has broken down the City into many prps. There must be a performance reason; either for the builders or the players.
Maybe it's related to vis regions? Do we know how we can manipulate vis regions for performance? I remember doing that many years ago when doing maps for the Doom and Quake engines.

A PRP file is one max file for Cyan. (From the mouth of a Cyan Programmer)

Vis Regions are something completely different

Sorry to bump this thread up, but I have a question.

If say you had two or more pages, and each page is a scene, each scene being part of the whole, like Ae'Gura, how then would we be able to line up the scenes so that the player can view it as one Age.

Another question is, how would I be able to copy and paste an object(s) from one scene to another without opening up another Blender file, to keep in tact all the materials, ALC script and so forth?

There is, in the Blender preferences, an option for a "Global Scene". If this works as it suggests, then all scenes could be viewed simultaneously.

If there could be some way to support both page_num properties and multiple scenes, that might work.

Trylon wrote:You can link an object to more than one scene by selecting it and doing CTRL+L.
After that it's linked to both scenes, and effectively shown in more than one scene. While any change in one scene will make it change in the other as well.
You'll need to be careful to unlink it from one of them, as a theoretical pyprp export would make a copy of the object for each scene.

If people are going to go through the trouble to link all their objects to multiple scenes in order to view them, then the plugin must not require people to unlink them before export. I'm sure you could write it to check whether an object has been exported already.

Indeed. I believe this exact solution has been discussed before. Under the proposed system, the plugin would both create the global scene, and of course, ignore it during export. It was actually looking like a pretty good system, until it was apparently decided not to implement it at the time.

Oh, it's still in the planning, but I can do only two things at the same time:
hearing no evil and seeing no evil