Guild of Writers

Hi all,

We (Deledrius, Luna, and I) have been spending some time working on Korman this past week. For those of you who missed out, Korman is the "next-gen" age creation plugin for Blender 2.6x that will export to ABM/Untìl URU, Path of the Shell, and MOUL. We've worked out some workflows that feel fairly natural in Blender, but we're still puzzling over one of the core components of the exporter. Namely, materials. One of the problems in PyPRP1 and Blender 2.4 (aside from AlcScript) is that what you see in the blender render might be totally different from what you see in Uru. We would like to fix that by using the Blender 2.6 nodes system to export materials. Many art and modelling packages (such as 3ds Max) are standardizing on the node paradigm, and we'd like to take advantage of that. Unfortunately, I myself am not an artist (nor a very visual person) so I am at a loss as to how such a system would work. We would appreciate your feedback on the Blender 2.67 nodes system and how you would want to create your materials in it.

There are a handful of benefits to using the node system--namely that we can tailor the nodes such that blender renders can very closely match what you will see in Uru. I'm sure I don't have to explain the immediate benefit: you don't have to reexport to see the age. Nodes are also a good way to visualize some of the more technical aspects of building complicated materials. I personally like some of the other possibilities, such as baking lighting and baking environment maps on export. . We'd really like for Korman to be a nice to use plugin. The best way to do that is to hear directly from the users, of course

I can also reveal that there will be no AlcScript in Korman. All features that required AlcScript in PyPRP1 will be exposed as graphical options in Blender.

Feel free to offer opinions other than those related to material nodes as well. We've got some general designs done and won't mind discussing them or answering questions.

Fantastic to hear, that finaly time is invested in the further development of Korman.
To build quality into future ages, this is of highest priority.
I am pleased to hear that you aim to support the node system in Blender.
This is without doubt, one of the main tools that determine in Blender, its current power.
In contradiction with this observation, I regret I can hardly handle the new node system.
Due to the fact it was not supported in PyPRP1 , I concentrated on alternatives, i suppose most agewriters where forced to do so.
I'm going to delve into this from now on, but before i gained experience enough to give usable feedback will take a while.
Also bump mapping, specularity, and displacement deserve attention in order to get good texturing.
But this is also woven into the natural nodesystem , i suppose.

I hope there are any agewriters who can provide you the required info.
In the mean time i wish you (the team) lots of succes in the development of this promising long awaited plugin.

Wow... That sounds promising !

Personally, I got used to Blender's materials. I already saw such node system in other game engines (Unreal SDK, mainly) but never really managed to get them working

In fact, I now check the output using the Blender Render (in Blender 2.6). I use all kind of features Plasma doesn't have (AO, ray tracing, soft shadows, ...). It results in something far beyond Plasma's limits. Then, I make a copy of the blender file, bake maps for most of the objects, and import the whole thing in Blender 2.49b. Then, I edit the materials to remove any dynamic lighting, shadowing, etc, and use only the textures/baked lightmap on export. So far, for the few test scenes I built, the result was really good, not too laggy and realistic.
It's long, but since I rely on almost none of the features from Plasma (dynamic/ambient lighting), I get a result that's close enough to what I get in Blender.


And although I love the idea of baking lightmaps on export, I'm still a bit puzzled...
How would we tell the plugin which object should cast shadows when baking, and which objects should cast shadows in Plasma ?


About AlcScript: very good idea to remove it. It was far from being intuitive IMHO.


Anyways, I wish you good luck making the plugin. It sounds really great.

I have no idea what Nodes are sorry.

I just use Blender 2.49b still and just work with the usual Materials I can get it to do what I want it to do just fine at this point.

In some software, nodes may also be called anchor points or tangent points. It is a type of software design which builds around modular components which can be connected to form a graph of the games graphics. Often the software's underlying architecture is also exposed to the end user as a 2 dimensional visualization of the node graph. The node graph architecture is popular in the film and computer games industry.

Nodes in blender are very versatile and powerful elements. All basic properties you can set in the material tab etc. are represented as nodes. But you can combine them differently and use more advanced options. Apart from that nodes are very customizable and because of that we can make our own custom nodes to use with plasma. I think that nodes are very much part of the "new" workflow of Blender and I think it makes sense to use these new more powerful features. Cycles also uses nodes for materials and can show you the results of your changes in the nodes practically realtime in the viewport, wouldn't it be cool if it worked the same way with fanages?

Yes, the new workflow will take time to get used to, but I think the new interface of Blender in general will take getting used to. A lot of things have changed. Because of that I think it's advisable to already start playing with the newer blender versions even when you cannot use it to make ages right now. Pyprp1 is already not really getting any development anymore and it probably won't get any anymore once a fully functional Korman is released.

That's why I would like to ask you(artists in general) that especially when you haven't used blender 2.5/2.6 yet to follow a few tutorials*, or just poke it a bit with as long a stick as you like to get an idea of the new interface and how you think the Plasma Age development could work for you. Korman is in very very early stages of development still, and not a lot of things have been decided on yet (apart from "no alcscript") , so be imaginative and tell us how you would like to create a fanage in Blender. Feel free to make interface mockups, screenshots, whatever helps to make your idea clear.





* I really like the tutorials from http://www.blenderguru.com/ myself, especially the ones with/about Cycles. The plugin won't be exactly the same, but we hope to borrow some ideas. There is also a cheatsheet on the site with the keyboard
shortcuts which is really useful as some of them have changed from 2.4 to 2.5.

EDIT : the blender interface concerning Cycles has changed since some of those tutorials were made.

Tsar Hoikas wrote:
I personally like some of the other possibilities, such as baking lighting and baking environment maps on export.

Although this sounds good in theory, it's probably not a good idea. Lightmaps can be baked in a few seconds, but high quality ray-traced lightmaps on complex geometry can still take 20 minutes to pre-bake on big modern machines. Imagine what that will do to the export time on a large age. Cyan's plugin "prebakes" vertex lighting, not detailed ray-traced lightmaps. Even then, to get decent results the poly count has to be increased dramatically. The industry has moved away from this type of lighting, so IMHO it would be counterproductive to build a feature into the plugin that encourages low quality out-of-date work. The professionals in the industry are still relying on pre-baked lightmaps combined with real-time lighting, so asking the three of you to code something above and beyond what the current industry standard is might be more wishful thinking than a good use of your time and resources. I'm not saying you couldn't do it, I'm just saying asking you to do this seems unreasonable IMO.

Getting the full use of the nodes system and all its capabilities would be awesome and makes good sense in a forward thinking plan. The industry is moving to this architecture, so it would be in everyone's best interest to learn it. For those of us already familiar with the principles of developing good textures in Blender or the older versions of Max, the learning curve to change to nodes is very low. Nodes are cool and once you get the hang of it, they're really easy to use.

I personally would prefer that you guys focus on making a powerful functional plugin first and worry about making it pretty later. Give me the ability to have real working normal maps on my textures and I won't care what the plugin looks like . After a solid functional powerful plugin, the next priority on my personal list would be excellent documentation.

There are two things that pyPRP1.X has that I love and would like to see in the new plugin. The first is the age.text file generated on export. I've learned so much from studying that text file and I hate that Cyan's plugin doesn't generate something equivalent (at least not that I've found). The second is Tach's alpha texture fix for Plasma. Alpha textures buffering properly in game engines is an industry-wide challenge and we have a huge advantage here with that file. We don't want to loose that.

We should probably put a disclaimer in here for the sake of the dev's and everyone's sanity that no amount of fancy software or hardware will ever take the place of a good artist, hard work and commitment to quality. But if we're going to dream, I would like you to code a plugin that allows me to scan a photo of a really cool place and have a "make age" button that turns it into a full fledged working age in Plasma .

Being very new at this, and not exactly sure what a node is, I'm not sure what I can suggest is a "good" idea or a "bad" idea, but if using the nodes system makes our exported age look (practically) identical to what we've built and rendered in Blender, then, GO FOR IT haha!

I've played around with some of the cycles render stuff in blender and so I'm very excited if you can get that part of it working to export... YAY ANIMATIONS! (check out the ocean modifier or fluid sim stuff! weeeeee)

Thanks so much for working on this, guys. Uru really isn't dead at all!

About how the interface should look:

Well, I guess adding new properties and panels like PyPRP 2 did is already a good thing.

A few ideas I had, though I don't know whether they were already planned...

- Use the World settings to generate the fog settings in the FNI file. It's tiring to see the same black fog in each Age, while it's relatively easy to modify.
Maybe it would be useful to tie the 3D window's max draw distance (yon) as well. In some big Ages, 10,000 units is not enough to see the skydome.
It might be worth keeping the "Fni" text file in Blender, though. In some cases, additional scripting might be required in it.

- Being able to write Python scripts directly in Blender's text editor

- Have the equivalent of quickscripts as GUI. For instance, selecting a door model, adding a "door modifier", setting an opening sound and animation...
Or make a linking book that uses a global Python file in which you would supply only a destination Age and spawn point... Or create a journal, set it's content to <journal name>, and in the <journal name> Blender text file, write this journal.
That would be better than the current Python script redistributed with each Age Diafero's complaining about

Calena wrote: I personally would prefer that you guys focus on making a powerful functional plugin first and worry about making it pretty later. Give me the ability to have real working normal maps on my textures and I won't care what the plugin looks like . After a solid functional powerful plugin, the next priority on my personal list would be excellent documentation.

It's not about it being pretty, but more about ease-of-use like "do you want this as node/checkbox/modifier/something else" or "what would a logical place for this checkbox be".None of us are artists really, we're making a plugin we probably won't use ourselves. This makes it fairly hard because we do not know what you need or how the interface should look for you to be useful.

The "Make Age" button is noted down, but I'm afraid we'll need to wait until Blender can be turn unicorns into magic to use for it

Sirius wrote:- Use the World settings to generate the fog settings in the FNI file. It's tiring to see the same black fog in each Age, while it's relatively easy to modify.
Maybe it would be useful to tie the 3D window's max draw distance (yon) as well. In some big Ages, 10,000 units is not enough to see the skydome.
It might be worth keeping the "Fni" text file in Blender, though. In some cases, additional scripting might be required in it.

This is actually already implemented

Sirius wrote:- Being able to write Python scripts directly in Blender's text editor

- Have the equivalent of quickscripts as GUI. For instance, selecting a door model, adding a "door modifier", setting an opening sound and animation...
Or make a linking book that uses a global Python file in which you would supply only a destination Age and spawn point... Or create a journal, set it's content to <journal name>, and in the <journal name> Blender text file, write this journal.
That would be better than the current Python script redistributed with each Age Diafero's complaining about

I'm not sure whether it is possible to create a global python file to use like that, but otherwise both of these features are planned afaik