help with basic material creation for 0.7

afecelis · Post by **afecelis** » Thu Jan 18, 2007 2:05 pm

Hi guys. I've been trying to get a glossy material but every time I render all materials show up as diffuse. I read the recommendations at the 0.7 exporter on what to take into account to create the materials, but now with all these new settings (A,B, alpha, beta, gamma, lambda, heheheh, kidding, only the A and B flags are true) and things like the new glossy-transparent material, SSS, and changes of how to use IOR and other technicalities I'm totally lost.

I was wondering if someone could start a basic material creation tut for 0.7. This way, when te time comes to update Radiance's tutorial it would be just a matter of replacing the info

Mainly screenshots with blender settings for:
1. Diffuse material (the one I get all the time!)
2. Glossy material
3. Glossy-transparent
4. Glass material
5. Reflective material (mirror)
6. A basic SSS material
7. Others (suggestions)

If I had the knowledge, believe me I'd write a tut on it or capture a howto video, but since I'm totally lost (I just had finished understanding how materials work in 0.6

) I'd appreciate it (and I'm sure others would as well) if someone could get this party started!

regards,
Alvaro

CTZn · Post by **CTZn** » Thu Jan 18, 2007 2:34 pm

I just had finished understanding how materials work in 0.6

Lol, I'm sypathizing with you afecelis, I did myself my first tries with 0.7t1 today, mainly with concern for textures I can't get to work, for some arcanic reason.

I'd appreciate it (and I'm sure others would as well) if someone could get this party started!

Hey, sure, but why are you posting this in the Blender specific forum ? Everyone is interested in that ! Or maybe you are talking about how to obtain such mats with a specific exporter for Blender, in wich case you can scratch what I say

afecelis · Post by **afecelis** » Thu Jan 18, 2007 3:10 pm

hehehe, no, not at all

. Besides, the idea in the end is to have a central source of materials we can share "a la Maxwell 3d". But that would mean xml standardized materials, and since our start point to create them is the material editor of the 3d modeling app we use, I thought it would be cool to know what settings have changed in the blender material creation process and how this will affect and reflect in the xml code; hence posting it here

Something like Radiance's examples:

For instance, he described Phong, mentioned which sliders to tweak in blender, and showed the resulting code.

regards,
Alvaro

Wedge · Post by **Wedge** » Thu Jan 18, 2007 3:12 pm

Hey there, I think it is time for me to give some of my thoughts on this.

I've been knee-deep in SSS lately trying to figure out the tags used when and where...Mostly without success. I am far too new with SSS to understand when this feature-A is on, turn this feature-B off.

I am < wide > open to thoughts on this right now.

I have rewrote SSS yet again but not updated it because as it turned out, I destroyed the entire loop. Funny thing is I forgot to make a backup so luckily I grabbed my own code off from my thread again and have a working version back in my hands.

I will say that I'm no pro at blender, python, or indigo first in case that my thoughts show up as incorrect or misleading, I am sorry, and if you can add or correct me, please do:

And now I will express my thoughts on how translation might be able to happen:

*Blender sees a material, whether it be glass, diffuse, reflective, shiny, dull, yellow, green, whatever, all as one material. No matter how complex it gets, blender shows it in the list as one material.

*Indigo sees a material as being a diffuse, a phong, or a SSS with the internal medium tags. Indigo sees mediums as a separate tag with separate values from a material. There are also a number of different kinds of materials within a material, phong, diffuse, .nk, blend (for material blend), and SSS. Inside SSS is even a number of different kinds of tags.

Add to the mix that some of these can be implemented without being directly applied to meshes, like mediums for instance. To my understanding, a medium does not get applied to a mesh but instead gets applied to the materials <internal_medium_name> tag. If you want to blend material-a and material-b, it is my understanding that you will need to create 3 materials in blender, with only one being applied to the mesh...the result of blending a & b.

Sort of like my current setup of material.medium where the glass.medium is not applied to any meshes in the scene.

I do believe as Radiance has said, things will be getting very confusing now. I am having huge problems going over and over in my head how the translation can be done, not only correctly, but efficiently and stable for the many scenarios you can create between materials, materials with blend phong or diffuse, materials as SSS, and mediums.

Phong and diffuse are fine, but SSS, mediums, blends, and all the different tags inside SSS will no doubt be a tough one.

* Can we export all materials in a scene regarless of their attachments to Meshes? Will this help us so that we can create glass.mediums and materialA.blend and things like this that won't be applied to meshes?

* Can we create one loop after that is done to identify the tag at the end of every material.... like ball.glass and apply the appropriate internal tags like medium, SSS, blend? While keeping also the path for phong and diffuse and to determine how textures get placed?

* Can we determine a clear way to let the exporter know what material is this? Can a .name tigger a blend and a medium? Can RAYTRANS and other buttons be used to determine SSS and other values be used to set the right <tags>?

I am wiiiiiiiddddeeee open for thoughts about this. After working on it so far, it makes me thankful at how easy indigo 0.6 appears. I am very very confused right now and can't make any progress with this.

Please don't take these thoughts as me sounding angry in any way or degrading any part/feature/program. I merely need to dump my ideas here and let someone else help me see the light...

We need to see the light because it will take knowing both blender and indigo to translate the materials correctly. That's what exporters do, they take info from here, and put it over there.

afecelis · Post by **afecelis** » Thu Jan 18, 2007 3:25 pm

Whoa! Wedge! Thanks for the valuable insight! But you're right; this only makes me love 0.6's simplicity a lot more. Though I know the new material system is way more powerful and the way to go (Nick showed some blend material screenshots that were amazing), you can also tell it has made things more difficult both for end users as well as for programmers and exporter writers. Many ideas crossed our minds when we saw the screenshots; one of them was using blender's node material system. But imagine if many users don't even touch it now that it's part of blender's material system...

But on the other hand, I'm glad users are pointing these things out since we got different levels of experience from people who can share their wisdom. And this is mainly happening here at the blender threads, which is quite active and counts with support from talented scripters, programmers and hobbyists. From what I've read, the other 3d package users are having a hard time not being able to try a semi-working script for their 3d app.

So, to end these words, this also makes me realize that the going will get tougher, on all sides!

CTZn · Post by **CTZn** » Thu Jan 18, 2007 4:40 pm

since our start point to create them is the material editor of the 3d modeling app we use

AFAIC, I have to disagree afecelis, for me the starting point is the xml syntax Nicks is providing, making a translator for this standard is a second step, isn't it ? The most universal way to share materials is via pure xml...

Or your is idea to create an importer for [xml->3d app], wich would then be translated in Blender's shading tree for instance ? This sounds a good idea that way

I'm sure Blender is flexible enough to allow this, I know Maya is, via simple scripting but I'm just an ignorant when it come to code

I think I'm gonna try to make the actual MTI evoluate but that means improvements would be to come in a few... months

It is not said I will (or will be able), yet.

The advantage of Maya is that it is easy to create dummy nodes and fill them with any attribute you wish, but looks like all Maya users are gone

this is mainly happening here at the blender threads, which is quite active and counts with support from talented scripters, programmers and hobbyists. From what I've read, the other 3d package users are having a hard time not being able to try a semi-working script for their 3d app.

This I have to agree, 500% ! Precisely, thats the reason why you see me here, and at the end if the Blender (importer/) exporter is the only one which fully works, its likely I will use a pipeline similar to Radiance's one.

I think it would be sane to debate this with everyone in the forum, letting the app specific aspect for further development. I believe also the syntax can be made more comprehensive, but that has to be decided by one person only, and thats fine to me

And Wedge... I see all your interventions to be very positive in a human aspect, thats just a clever way to go

IMHO competition should not exist between individuals while the aim is to provide the best for ALL !!!

We need to go the best way for all, that's why I'm defending the idea of creating a thread in a common forum to debate about further orientations (material sharing, conventions between devs etc etc), and of course only if that sounds ok to Ono-Sendai

zuegs · Post by **zuegs** » Thu Jan 18, 2007 7:12 pm

Hi all,

yes infact the material mapping between indigo and blender is a big problem. The python API for the new node-materials from blender is not ready yet, i think. The standard blender materials was just good enogh to map v0.6 indigo-materials but for v0.7 materials i think we need a new idea.

CTZn wrote:]Or your is idea to create an importer for [xml->3d app], wich would then be translated in Blender's shading tree for instance ? This sounds a good idea that way

That's infact what i was thinking about. We need a way the user can edit indigo-materials directly, a sort of a material-editor, that directly read and write materials in XML. Additionaly it could try to simulate the indigo-material in blender with a blender-material.
But my first big problem here is that Blender comes without Python's XML librarys...
So we need a very simple and compact XML reader/writer that can be embedded in our script

Anyone please tell me where i can find such a simple XML reader/writer

YaroslavL · Post by **YaroslavL** » Fri Jan 19, 2007 9:40 pm

Hi everybody!
Sorry for my EN.
As I understand the problem is in blender material editor gui?
As I know in 3dmax, for example, when we choose vray as renderer engine - we have new (vray) material editor interface! When we choose mental ray - we have another (mr) material editor interface. So why you guys trying to describe indigo materials with strange for him blenders material settings?
I understand, that there are many standard mat properties, but, may be the better way is creating the indigo+blender compilation as program? Not as script.
Unfortunately, I'm not a programmer, and can't help in it. Sorry. But I know - MANY blender users (and blender+Linux users) really need your renderer!
Blender is great modeler, but it's rendering engine is bad fo architectors and interior designers...
So what do U think about new compilation of "blendigo" with new material editor intrface?
:O)

tungee · Post by **tungee** » Sat Jan 20, 2007 6:36 am

yaroslav, thats right!.
i dont how hard this will be, but there is kerkythea, mental ray builds with own mat editors i think that better.
an integration like yafray would be the best solution!

Phil · Post by **Phil** » Sat Jan 20, 2007 7:01 am

Hi,

I am not sure to understand you YaroslavL.
Do you mean going away from python and compile a nextra blender version?

Regards, Phil

afecelis · Post by **afecelis** » Sat Jan 20, 2007 7:36 am

No, not going away from python, but getting blender's source, modifying it and and integrating Indigo as another renderer that you can select; (just like you select yafray now, and it's well integrated along with its own material options). This would immediately enable the indigo material options (new menus and sliders) that will comply with the new xml format.
There are other succesful attempts liek this; blental (blender to mental ray,the one mentioned above), blend2pov (povray), blend2kt (kerkythea's blender version) and Yafaray (updated yafray engine). But the most succesful attempt has been Yafray whic hsa been included in blender as a default alternative renderer.

Sounds like a good idea, but the problem now is: who can code it?

Phil · Post by **Phil** » Sat Jan 20, 2007 7:48 am

Hi,

ok, I understand now, the idea sounds great

but the problem of coding this, seems also to be great challenge!

Regards, phil

StompinTom · Post by **StompinTom** » Sat Jan 20, 2007 8:58 am

itd be so much easier if Blender's node system could be used to make Indigo materials (ie. an Indigo material plugin) but, alas, that is not to be. does anyone know what the situation is with Blender nodes these days? i mean as far as customizability and such go.

tungee · Post by **tungee** » Sat Jan 20, 2007 12:50 pm

exactly this was ment by me afecelis, but this must be very hard to code.
Who coded the kerky blender build ?

afecelis · Post by **afecelis** » Sat Jan 20, 2007 3:12 pm

tungee wrote:exactly this was ment by me afecelis, but this must be very hard to code.
Who coded the kerky blender build ?

JMS (JM Soler), one of the major blender script writers (along with Cambo).
http://cobalt3d.free.fr/images_3dblende ... kythea.htm
But I haven't seen him around here much...or at all

He also wrote the 1st working POVray exporter (before JCRuiz wrote Blend2POV).

help with basic material creation for 0.7

help with basic material creation for 0.7

Who is online