Guild of Writers

Yes of course, a combination of scene-related and property-(page_num-) related would also be great, with export excluding.

I only mentioned the principle of PyPRP2 for the developers, so they know where to look in for the scene-related stuff. If they do not already know/remember?

Ok last one off topic lol

The export script is here in Sirius post 489

http://forum.guildofwriters.org/viewtop ... 4&start=20

Jojon wrote:
BUT there would be none of the unclarity and behind-the-scenes "magic" that comes with translation.
-If you set the Alpha flag for a layer, you know you have set it, without having to associate it with a Blender button that has a "similar function", and without having five other rules-of-thumbs and bits-of-conventient-automation, triggered by different parts of the exporter, "changing it behind your back".

It just feels like you have a little bit of comforting control, when you work directly towards the actual final target platform, than when you write in Swahili and then feed the text through Google Translate to get English.
At least you have only yourself to blame when things don't work.

I have no idea what so ever how complicated it is to either write Blender editor shaders that mimick Plasma's behaviour, or a conversion script that can take a Plasma-centric "source" node chart and create an equivalent Blender material, based on that (whenever you change the "source"), only for use while editing in Blender. (...but as I mentioned; I might even find it acceptable to work "blind".)

I'm not sure I entirely understand your issue, so please correct me if I am wrong, but a large part of the awesomeness of Blender 2.5+ is that the addon will be able to change the interface, hide buttons/menus/properties, make new ones etc. as necessary. So it wouldn't be "hidden" behind some obscure blender button, but behind a button named something like "Plasma alpha" or just "alpha" in a Plasma menu.
Also as Hoikas mentioned, we are planning to use nodes to bring the Plasma materials to Blender and thus make the whole progress less "blind".

That simple, is it? All good and dandy,then. :)

I know nothing about anything, which is no doubt immediately obvious to anybody who does, and I have played with neither nodes in Blender, nor Blender 2.5+, for any more than a scant few minutes each, but I would have thought things to be a little more complicated and less flexible than that under the hood, even if the GUIs on top can be customised to one's heart's desire.
E.g; I would not expect every paradigm/implementation beween Blender's and Plasma's material systems to be directly compatible -- is what Plasma does with the layers listed in a material conceptually exactly the same as a Blender layer stack, for instance (I seem to recall layer order is not always preserved in export, and have no idea whether one can just keep adding more and more layers and see them applied in turn at time of render, or whether there are rules, or "slots", or hardcoded processing orders, or other limits of sorts), what about value ranges and so on?)

Glad to be wrong - I am guessing the node-based material definitions in Blender pretty much side-steps the normal panels, replacing their functionality with a "less monolitic" model.


Anyway; Just "using nodes" in itself, does not necessarily mean one bring Blender closer to Plasma and what I was getting, was that Adam wanted to know how builders would want their workflow to go.

My input, basically, was that while I have never built any materials using nodes and as such speak ignorantly; Should the choice ever stand between making the builder's setting be directly representative of the Plasma material as ones and zeroes, OR look visually right in Blender, whilst putting a few conceptual bits of middleware between builder and Plasma, I'd find the former a much more palatable tradeoff than the latter.

(Blergh, too many words to say too little)

I'm still trying to read through some of these posts, but I do see a few things I can comment on

It depends if materials look different. If you are using shadeless materials, which are not affected by any light source (neither in Blender nor in Plasma), textured materials look quite similar. I assume you already know that, just mentioning to better explain why shaded materials in contrast are difficult.
The visual outcome of shaded materials - which should be used rarely in an Age by the way - does not only depend of the material's settings itself, but also (and highly dependent) on the used light sources. This lies in the nature of shaded materials. If a surface appears bright, medium-lit, or dark, not only depends on the distance and lighting angle (face normal to light beam direction), but additionally on the behavior of the light source. That is, how it's falloff is defined. Inverse linear, logarithmic, cubic, whatever. And the maximum distance where virtual photons have effect, if applicable. So you only have a chance to make Blender renders compareable to the outcome in Plasma if you can ensure that light source behaviour is absolutely identical in Blender and Plasma.

You understand what Uru's rendering pipeline was designed to do and understand how to get good results out of it, then. Unfortunately, this is really not obvious unless you have someone walk you through it or figure it out yourself through lots of work. I would like for Korman to use blender lights to preshade as much as we can and hide the whole "shadeless" thing as an implementation detail. Hopefully, this will automate the majority of your workflow. I only have vague ideas of the pain involved in creating good ages with PyPRP, but it's enough to make me cringe. One of the design decisions I made when starting Korman was that PyPRP (both versions 1 and 2) exposed way too much in the way of Plasma baggage to the user. I'd like for there to be enough options for you to do awesome things. But, at the same time, there is really no need for us to be tweaking things like drawable flags in some crazy YAML file

There were some points about the way pages work in the various PyPRPs. Korman's page management actually works more like the 3ds Max plugin. On every object, there is a "Plasma Object" block with a checkbox beside it. If you want the selected object to be exported, you enable that box. The first time you click it, a "Page" property will be initialized. It will select a page whose number is the same as the layer the object is on. You're free to change that however. Pages are identified to you by name (not by number--that's an implementation detail). I don't have all my plugin dev stuff on hand right now or I would post a screenshot.

Jojon wrote:Anyway; Just "using nodes" in itself, does not necessarily mean one bring Blender closer to Plasma and what I was getting, was that Adam wanted to know how builders would want their workflow to go.

Indeed. We know the Uru engine, what it expects, and what it's designed for. I mainly want to know how you would like to work with material nodes. I'll figure out how to translate them to Plasma materials.

Tsar Hoikas wrote:Korman's page management actually works more like the 3ds Max plugin. On every object, there is a "Plasma Object" block with a checkbox beside it. If you want the selected object to be exported, you enable that box. The first time you click it, a "Page" property will be initialized. It will select a page whose number is the same as the layer the object is on. You're free to change that however. Pages are identified to you by name (not by number--that's an implementation detail).

Now that sounds really great. This would make everything at lot easier.

Tsar Hoikas wrote:We know the Uru engine, what it expects, and what it's designed for. I mainly want to know how you would like to work with material nodes. I'll figure out how to translate them to Plasma materials.

See, Adam, we the designers do not really know all Plasma's features when it comes to materials. Ok, some may, I know some as well, but most of my knowledge is derived from what PyPRP1 provides and does. Plus some ideas I got from the forums when someone was asking "I can't find this or that option. Oh wait, there's no bumpmap option at all? And no specular maps?". It's not really clear to us if it's just Plasma that does not support specular maps or PyPRP1.
So what are the options we are talking about?

I know that Plasma can handle (derived from PyPRP1 options):
- Object color
- Specularity color
- Specularity value
- Reflection value
- Hardness (not sure)
- Ambient value
- Emit value
- Shadeless option
- Texture amount (or whatever the Col slider in Map To should be called)

Please correct the list if needed, and add options plasma supports.
Give us some names, then we can think about how we would set this up in nodes.

And maybe there's a misunderstanding regarding nodes. Do you want to use the node system just internally for calculations, and provide a GUI with checkboxes, dropdowns, value fields like the Max plugin instead?
Or do you expect us really to setup material nodes for each material like shown in these images:




(Source: http://wiki.blender.org/index.php/Doc:2 ... pes/Vector )


I for sure must make myself more familiar with those nodes, but currently I'm thinking "Why must I setup such complex operation trees with lots of windows for each material when I could do the same before by simply entering some values here and there in already available fields?"

See, we are not talking about some few materials. We are talking about hundreds. Relativity for example uses about 300(!) different materials currently. And that's not overdosed, but low average. All those materials are needed because each object has it's own lightmap, and therefore you can't re-use the same material even if it is similar, but you have to create a new (copy works well though) to assign a different lightmap. And most objects are multi-material objects.
This would mean to draw 300 node trees.

I'm sure you have reasons for preferring the node system.
First I assume it must be fun to play with nodes, and write Python code to manage them nicely. That would truly be a respectable reason and not underrated; the motivation for writing tools for age building is the same as Age builders have: It's just fun to explore all the possibilities, and positive feedback from the community is the bread we all work for.
Then the reason could be that using nodes is the only way to get the display in Blender more similar to Plasma. If that's the reason, then it must be.
A third reason - and I assume that's it mostly - is that you want to give us just state of the art tech for Age building. Great, and really appreciated, but if we can get this only for the cost of slowing down the building process and confusing most of the builders - reading the thread gives me the impression noone is really familiar with nodes - and we don't have much Age builders left - then I fear some may not like Korman that much as you expect.

I really can't tell pro or dont currently, and howto not at all; starting to explore material nodes in 2.67 now, to get a feeling how complex node trees for average materials will grow.

Tsar Hoikas wrote:I would like for Korman to use blender lights to preshade as much as we can and hide the whole "shadeless" thing as an implementation detail. Hopefully, this will automate the majority of your workflow. I only have vague ideas of the pain involved in creating good ages with PyPRP, but it's enough to make me cringe. One of the design decisions I made when starting Korman was that PyPRP (both versions 1 and 2) exposed way too much in the way of Plasma baggage to the user. I'd like for there to be enough options for you to do awesome things. But, at the same time, there is really no need for us to be tweaking things like drawable flags in some crazy YAML file

I understand your motivation, and really appreciate it. We should get rid of too much Plasma baggage.
Regarding the pain involved in creating good ages, I can tell you it has not so much to do with material settings directly. When you've build for a while, you get a feeling what values to chose as a starting point. Then you visit the age, and tweak the values slighly, and that's it. The real pain comes into play when you bake lightmaps; from now on you are in trouble, because most of the values (Amb, Spec, ObjColor, Reflection, Shadeless, ...) are used for export AND the Blender rendering/baking process. This makes the whole process badly reproduceable.
For example, you've nearly finished an object, its lightmap is done, but because the objects needs a bit more light in the game, you increase the Amb, Emit or Reflection value slightly, and just export again without baking the lighmap again. Then, if you have to re-bake your lightmap later because you added more objects, the lightmap will come out completly different, which will require further tweaking again.
That's something we must absolutely get rid of.
Jogi mentioned how he does that in PyPRP1 by using different material assignments (OBject or MEsh) for rendering and export, to get rid of this problem.
I can imaging to have completely separated material settings for baking and Plasma in Korman, where the (already available) material options in Blender are used for baking, while a new set of material options (those you add) are used for export and Plasma only.

EDIT:
For your convenience, here's a document I wrote describing how we (Calena and me) are baking lightmaps currently.
It shows well how difficult it is, because you can't store optimal values in the design file, based on the fact that most values are used for both export and baking, so you have to change those values manually again and again on each baking process.
Relativity_Lightmap_Baking_V02.pdf

@tach:

I am assuming there may be a larger GUI road choice than immediately meets the eye here, because if the inkmakers go with the node system for materials, it seems to make sense to be consistent and use it for other things (potentially *everything*) in Korman as well, such as the logic we markup in alcscript today.

So; Custom Nodes or Custom Panels? (...like we're used to work with in PyPRP1 today, but with buttons for Plasma-irrelevant features taken out and missing ones added, and scaling of ranges of values, as well as automation, etc, designed to whatever seems user-friendly to us; the consensus of the wishes of the builder community, weighed against practical concerns that the inkmakers may have (make sure to speak you mind now, I suppose, everybody :7.))

The immediate user benefit of nodes, compared to panels, is that they give you a drag-and-drop "flowchart" graphical overview of the entire interconnected web of components you are working with, removing the "need" to follow the trail of references across different panes and tabs.

I am also assuming the inkmakers can construct node systems to abstract just about anything they feel like, and that we have at the very least the option to have this new one, for Plasma materials, exist alsongside Blender's internal materials one.
Maybe they could make materials of the new type always work right away in the editor, maybe they could keep the two types separate, so that we have one material for export and another one in the Blender editor/renderer, or maybe there could be something that goes half way, where each material have something like an "auto-translate" checkbox and/or a "translate now" button, which create/update a "work copy" named the same as the "source" material, with an ".i" suffix, or something.

How such a new "Plasma material" node (...or panel) system looks and works, and before that; which to go with, is what is up for deciding, if I'm not misunderstanding.

With the 1:1 Plasma representation that I (possibly alone) advocate, the nodes would be Plasma objects and look almost exactly like windows in PrpShop - bulky and content rich, as opposed to the flexible, but potentially quickly-becoming-complex-looking fragmented operators paradigm, seen in your screenshots (...where every mix and modifier is its own node).
There are still many different Plasma objects, mind you; E.g: A Mipmap would lead into a Layer, which in turn would lead into a Material (which can take an arbitrary number of inputs) and the Layer could optionally take a Layer Animation, which itself would have 9 inputs for a rather large array of controllers (curves, etc), and Synch flags, and so on.
(EDIT: keep in mind, though, that this is really no different than what you have already: you have Blender Texture blocks, which slots into a Layer, which slots into a Material...)

I expect it should be the simplest of final touches, to include a selection of material templates, with Korman.

I really believe it would be worth it, for the minimisation of abstraction, though...
Others will obviously want as much high level abstraction as possible. :)

Sorry about being so slow to respond. I'm doing some incredible time juggling right now.

tachzusamm wrote:See, Adam, we the designers do not really know all Plasma's features when it comes to materials. Ok, some may, I know some as well, but most of my knowledge is derived from what PyPRP1 provides and does. Plus some ideas I got from the forums when someone was asking "I can't find this or that option. Oh wait, there's no bumpmap option at all? And no specular maps?". It's not really clear to us if it's just Plasma that does not support specular maps or PyPRP1.
So what are the options we are talking about?

Heh, good point. In my typical fashion, I rushed off without providing all the needed information. Here are the features that I can think of (off the top of my head).

• Layer colors: preshade, ambient, runtime, specular
• Layer Opacity
• Layer texture (2d image, CEM, Dynamic CEM, Dynamic Plane [moul, myst v], Dynamic Text)
• Layer Vertex & Pixel Shaders**
• Projected Textures (lights)
• Runtime lighting on/off
• Du/Dv Refraction Maps ("bump mapping")

** Shaders are not exposed to the artist in any meaningful way at the material level. These are most often added programatically by other modifiers, such as water, grass (myst v, moul), and bubble shaders (myst v).

There are probably some features that are hidden very deep inside the DirectX pipeline code that are triggered by various flag combinations that I haven't found yet. I'll be sure to trace out all those pesky hsGMatState buggers and see what they do. IIRC most of them are used in the 3ds Max exporter as part of the baking process and don't actually have any effect at runtime.

The end goal (for me) is to achieve a material system that is at least as good as the one in Cyan's Max plugin. So, that would mean creating nodes that are probably similar to what Cyan did in 3ds Max. The nodes that are in Blender's Cycles engine are pretty infeasible because that engine is very different from Uru's. Besides, I would probably end up shooting myself if I had to design a complicated node graph (like your example) to test my own plugin. The benefit here is that you would have one group of material settings for exporting and baking your lights. So, your entire lightmapping document would be condensed down into two steps: 1) create materials like you want them to look in Uru 2) press "bake." The internal baking process would use settings that are identical to your document (yay, less tedious busy work). I was actually very pleased to see that your process is very similar to what I had mentally termed the best practices for LM generation

The fun part here is that most of these settings are per-layer in Plasma, but in Blender they're per-material.

Jojon wrote:it seems to make sense to be consistent and use it for other things (potentially *everything*) in Korman as well, such as the logic we markup in alcscript today.

The conditional object stuff will *definitely* be node-based. It's a really good way to model that sort of stuff.

I've taken a quick screenshot of the current world properties menu of Korman to show how we can change the interface. Here you can create pages and change the settings that end up in the age file

Edit: btw it looks kinda stretched because I dragged the menu wider in blender.

Edit2:Added picture with default width:

Does Korman handle Particles?
There is a discussion on the Moula forum around realistic fire's using Particles.
Chloe figured it out for 3DMax.
If we could do this in Blender, that would be great.