Indigo Renderer Forum

Since google code is shutting down, we moved Blendigo to GitHub.

https://github.com/glaretechnologies/blendigo

Pull requests welcome

Awesome!


Sent from my iPad using Tapatalk

I'd very much like to see Headrooms and FakeShamus' great additions to the exporter ASAP.

I only have one little complaint: the Null material that you guys added, seems to have been placed where External material was before. So whenever I open an old scene with an external material in it, all the external materials get replaced with a Null instead. I was quite surprised to see most of my whole Aston Martin disappear, with only the details like headlights and wheels left hovering in the air.

hey, sorry about that - it looks like this fixes the problem.
in material.py the properties list should look like this:
I had added in the null material above external in the menu list. it must save your material types by index of some sort, so null was taking external's place. Headroom, do you want to edit your working version to correct this?

I patched FakeShamus fix into Blendigo and have attached it to this post.

@Oscar J
PLease test it and see if it works on your older scenes. If so I'll see tat I create a pull request on GitHub to get these changes into the official repository.

In general I've come to the conclusion that Blendigo would benefit from some internal overhaul.
When you look at a scene file (.igs) that Indigo itself creates you can see that Indigo works with ID numbers, so most elements have a unique ID that can be referenced. As such Indigo's own output is not so reliant on the order in which the scenes elements are created because it can use these IDs to connect the things that need to be connected.

Blendigo on the other hand relies strictly on the sequence in which things are created in and that makes it difficult to add things to the code because you have to shuffle code around not only in one part but sometimes in several.

Headroom wrote:I patched FakeShamus fix into Blendigo and have attached it to this post.
In general I've come to the conclusion that Blendigo would benefit from some internal overhaul.
When you look at a scene file (.igs) that Indigo itself creates you can see that Indigo works with ID numbers, so most elements have a unique ID that can be referenced. As such Indigo's own output is not so reliant on the order in which the scenes elements are created because it can use these IDs to connect the things that need to be connected.

Blendigo on the other hand relies strictly on the sequence in which things are created in and that makes it difficult to add things to the code because you have to shuffle code around not only in one part but sometimes in several.

As far as i can see the Blendigo follows very straight the Blender API / Design Pattern for modules/add-ons. Maybe it is a little bit outdated and some code cleanup is necessary... but not really difficult.

I just started to take a deeper look in Blendigo (try to implenent the basic node system for material) and also i am new to indigo render so maybe it is much more work as i can see now

BTW. what is the latest indigo .igs documentation? i only found http://indigorenderer.github.io which very outdated (last update 2010?!)

If it's easy for you then I am guessing that you are more experienced with Python. Not that that is much of an achievement, because I started learning Python to understand the Bendigo exporter a couple of months ago and don't rally have the time to dive as deep into it as I'd like to.

You can find the latest technical reference following the link below. The most complete reference is still the PDF, which is from 2011.

If you are new to Indigo - welcome on the forum BTW - then we can help you with the Indigo specifics.

If you have questions, I can post an example of how Indio itself outputs .igs files.

http://indigorenderer.com/indigo-technical-reference

Sent from my iPad using Tapatalk

Thank you for the link. For me is python not the problem but i have to dive into the blender API and the indigio documentation which consumes some time.

I will see what i can contribute next to blendigo. Maybe it is a good idea to implement some other missing materials (oren-nayar, diffuse transimtter) and to clean the code a little bit?! i don't know

At the moment it is not easy for me to find out what is missing. someone have list (beside of node support) of features which are missing? this would help a lot...

zurkdahool wrote:Thank you for the link. For me is python not the problem but i have to dive into the blender API and the indigio documentation which consumes some time.

I will see what i can contribute next to blendigo. Maybe it is a good idea to implement some other missing materials (oren-nayar, diffuse transimtter) and to clean the code a little bit?! i don't know

At the moment it is not easy for me to find out what is missing. someone have list (beside of node support) of features which are missing? this would help a lot...

Oren-Nayar and Diffuse Transmitter materials are already implemented.

What would be very useful would be to de-couple surfaces from mediums when dealing with Specular materials. Sometimes it is useful to use the same medium from different surface materials (i.e. specular, glossy specular, etc.) so having it setup as a consistent, single medium would make adjustments safer and easier.

Also, material layering needs some thought and design work, as right now you have to make 'dummy' materials and make them persistent ('F', save the datablock with no users) in order to be able to use them with Blend or Coating materials.

A node system would be ideal, as I imagine that would become much more modular as well, though I am not sure how to implement that with Python.

I am not sure either how to do it as I don't have enough experience with Python , but I am sure it can be done because Luxrender has done it already. They started with it several years a go and their exporter is far ahead of what Blendigo has to offer. Not that Blendigo is bad by any means but it needs some overhaul and a node based material system has been on the wish list for a long time now.

Then of course the light later stuff needs an overhaul as well.
I added the ability to add emission scale to external materials and I am sure the other Blender users her can come up with a nice list.

I actually looked a the Luxrender Exporter to see how it's done. The Luxrender exporter still uses the same extension framework that Blendigo uses, simply because Doug Hammond was the original author of both Exporters.


Sent from my iPad using Tapatalk

Headroom wrote:I am not sure either how to do it as I don't have enough experience with Python , but I am sure it can be done because Luxrender has done it already. They started with it several years a go and their exporter is far ahead of what Blendigo has to offer. Not that Blendigo is bad by any means but it needs some overhaul and a node based material system has been on the wish list for a long time now.

Then of course the light later stuff needs an overhaul as well.
I added the ability to add emission scale to external materials and I am sure the other Blender users her can come up with a nice list.

I actually looked a the Luxrender Exporter to see how it's done. The Luxrender exporter still uses the same extension framework that Blendigo uses, simply because Doug Hammond was the original author of both Exporters.


Sent from my iPad using Tapatalk

*ahem* chopy pasta

Headroom wrote:I am not sure either how to do it as I don't have enough experience with Python , but I am sure it can be done because Luxrender has done it already. They started with it several years a go and their exporter is far ahead of what Blendigo has to offer. Not that Blendigo is bad by any means but it needs some overhaul and a node based material system has been on the wish list for a long time now.

Then of course the light later stuff needs an overhaul as well.
I added the ability to add emission scale to external materials and I am sure the other Blender users her can come up with a nice list.

I actually looked a the Luxrender Exporter to see how it's done. The Luxrender exporter still uses the same extension framework that Blendigo uses, simply because Doug Hammond was the original author of both Exporters.


Sent from my iPad using Tapatalk

I agree ...the luxrender exporter (which i used quite often ) using the same framework. it could provide a possible way to implement it into blendigo but just 'copy paste' is not so easy as it seems... at the moment i study the pynode api from blender. together with the luxrender exporter and maybe the example code from matt ebb there is a way...

at the meantime i am decouple the medium from the material...

Juju wrote:

Headroom wrote:I am not sure either how to do it as I don't have enough experience with Python , but I am sure it can be done because Luxrender has done it already. They started with it several years a go and their exporter is far ahead of what Blendigo has to offer. Not that Blendigo is bad by any means but it needs some overhaul and a node based material system has been on the wish list for a long time now.

Then of course the light later stuff needs an overhaul as well.
I added the ability to add emission scale to external materials and I am sure the other Blender users her can come up with a nice list.

I actually looked a the Luxrender Exporter to see how it's done. The Luxrender exporter still uses the same extension framework that Blendigo uses, simply because Doug Hammond was the original author of both Exporters.


Sent from my iPad using Tapatalk

*ahem* chopy pasta

Huh ?

I just started to write 'issues' on github. Maybe it is a better place to have a overview about enhancements, bugs and so on?!

If they are "issues" such in as bugs or serious limitaitons that would be the correct place to put them. For feature requests I am not sure it will receive a better response but is probably a better place to collect information as opposed to the multiple threads and posts that conatin those.