Indigo is great, but...

[Labello]

Hey Com!

I was wondering about the fact why maxwell is so much more successfull than indigo although indigo has got basicly the same power and is much more cheaper than maxwell.

I think it is the way how Indigo is presented to a new User or someone, who is looking for a good rendering-solution.

Someone who whants to get indigo to know and downloads the Manual and the fitting exporter for his 3d-app is confronted with a huge amount of physical and specific terms which might be frightening. these terms might be right and very usefull and of course neccesary for the developers but a real user who just wants to produce nice images wants to have something else.

he wants self-explaining buttons in the exporters, easy to understand manuals but without a lack of functionality and professionality. It starts with the different types of Materials. They should have at first nice names, which dont have to represent the method these materials are calculated or something. and it definately doesn't end with the fact, that in Blendigo the color-texture-path is written in the albedo-box? why isn't it called simply color-map which might be more comprehensible for everyone?

Everything i want to say is that indigo has got a extremely high power and can be used to kick maxwells ass. but still just by users who have been using it for several months.

so why don't we try to improve the workflow in indigo and it's exporters. cuze it is such a great piece of software with all it's exporters and so on. so everything the com has got to do is polishing the face of indigo, by writing basic and fancy tutorials, creating a manual that is made for CG-artists and not for physics-students or create scene-presets. the first step in this direction was already done by creating the materials-database, which is great!

so i would suppose that we collect some SERIOUS ideas to make working with indigo easier for newbies without loosing the pros

again: i don't want to critize the work of ANYONE in this community. it is great. i just want us to focus on something else than we did before.

greetz Labello

PS:please don't get angry xD i am not very good at expressing my ideas in english xD

[CTZn]

Nice initiative

I think the wiki is the ideal recipient for this all, it needs indeed more input and is of public access.

Maybe the wiki needs a specific forum to coord these actions first

[BbB]

For idiots like me, the learning curve can be quite steep, that's right.

BUT... consider these few points:

1) Have a look at the zillion complaints on the Maxwell website about crashes and bugs. There's hardly any support these days. The user base is clearly quite frustrated.

2) Have a look at the number of updates. Not that many. The last one is I don't remember how many months ago. For a $1,000 app. It's also easier to have proper documentation if you only get new features once a year.

3) Indigo is developing very fast. The latest update (together with the exporters) have brought quite a few problems, which must be sorted out before you even start thinking of a polished documentation. Ironing out the kinks, I believe, should be Ono's and the exporter writers' priorities.

Clearly, displacement and the latest features are hugely complex to implement and Ono is constantly rewriting his code. This, I think, should really be the priority right now. We can always think about the doc once things have settled a bit.

[Labello]

@CTZn:
The wiki might be just a first step, to collect the material but it should be composed to something that is downloadable or even burnable to a cd

@BbB:
Your argument is not very strong, because you can always say that there are more things that have to be done before making a feature-freeze, and focus on the stuff around. like that you will never be able to get where maxwell is.

i might be wrong but the indigo-com is really active and very nice to newbies. in contrast to maxwell. so if the developers would stop adding features and focus on workflow and usability(which might be also features, but u know what i mean) we could make indigo more attractive, when everything seems like from one hand. and in this part the whole com is asked to contribute.

i just found several projects related to indigo to improve indigo... the only thing that has to be done is to stitch these apps together to one whole thing:

http://www.indigorenderer.com/joomla/fo ... 42&start=0

http://www.indigorenderer.com/joomla/fo ... 90&start=0

http://www.indigorenderer.com/joomla/fo ... php?t=4120

[CTZn]

I want to point out that the first one initiated with a commercial project from the author, IIRC Ono didn't give much credit to that.

The latter can be seen as a replacement, maybe.

Isn't the point here to make all user-created tools open source, so the projects do not fade out that fast ?

[Pibuz]

Hi labello!
Yes, i partially agree with you.. I think maxwell's interface (seen as its way to present to new people) is more..sensual. I remember the first time i heard of this Indigo i had a look to the site and i found it only worked with command lines. I thought: Oh no! How can i handle this?!
Then after a little passing of time i came here again and found that someone had written a sort of exporter from sketchup, so i started to follow the line and to test things. I really think someone needs a little patience and a great passion, cos Indigo is extremely powerful but - AS ANY OTHER SOFTWARE - needs to be understood to be used properly.
So, i don't think it's mere matter of words (albedo instead of color: after you know what it is, what's the difference?), what indigo lacks at the moment; i perfectly agree with you about the tutorials and manual topics, instead.
To be sincere, i already thought about writing some tuts, just because, like you, i think that it should be very useful for the very new users to have some pdf files to download to know the current features of Indigo. Indeed, the thing of writing tuts and even a manual is an idea that really excites me.
But i see two problems:
1. I'm NOT a pro user of SkIndigo: i don't know anything about ruby and coding in general, so i could only explain which settings do what, with no theory at all.
2. Indigo actually develops SO fast. So, i think any of us is scared to write a manual which will be potentially useless in 1 month. It is true that many features will remain, but what if the user's interface needs to be changed?

However, if you all say it would be a good idea, i'd start working on a SkIndigo manual even tomorrow. Be careful cos the will is strong, but the means are what they are. Perhaps i'd need someone to read my in-progress version of the manual to check if it's acceptable or not..

Let me know what you think!

[Labello]

I want to point out that the first one initiated with a commercial project from the author, IIRC Ono didn't give much credit to that.

The latter can be seen as a replacement, maybe.

Isn't the point here to make all user-created tools open source, so the projects do not fade out that fast ?

I don't get what you want to say with that post. Can you explain it please?

[CTZn]

Yes sure, sorry that was quite synthetic.

1° The person who develloped IndigoExplorer was waiting for Ono to give permissions for a commercial (paying) online rendering solution before further development. But Indigo license is clear, this is forbidden. This project (IE) should not be invoqued IMHO, only as a reference for a future (free) tool.

2° If a program is open source, this means anyone can grab the code and pursue what had eventually stoped earlier. The projects would not be bound by one person anymore.

I can explain further if you need

edit: for 2°, from the IGS-Viewer thread:

good idea! if its gonny be open source, count me in

Open-source (or gpl licencing or such) is a requirement for a collective coding project, at least as far as I know.

[Labello]

Hehe i know the advantages of OS I use Ubuntu and Blender xD

I just linked to this threads to show that there is motivation in the community to develop indigo into another direction than just new rendering-features.

But i think the first thing what we need is something like a "well cool idea" from our master

then we could start to make a plan how to get indigo to the top workflow level

greetz

[Stinkie]

For a $1,000 app. It's also easier to have proper documentation if you only get new features once a year.

I'm not that impressed by the Maxwell manual either. Quite often, it explains what a tool does, but NOT how you're supposed to use it. lol.

I find that a bit of a shortcoming.

EDIT: part of Maxwell's attractiveness lies, ironically, in it's steep price, I believe. It's human nature: the more expensive something is, the more people want it. If Indigo were sold for, say $ 400 (with the exporters included), it's popularity would rise, I suspect.

[Pibuz]

If Indigo were sold for, say $ 400 (with the exporters included), it's popularity would rise, I suspect.

Oh, yes.. But we old boys would have it for free, isn't it?

[BbB]

I don't know. I still can't help feel it's all a little bit early.

Look, displacement was a major step. It's changed the code quite a bit. The exporter writers are struggling as a result. Right now I feel our priority as users should be to stress-test Indigo and the exporters to make sure they're rock solid. I mean running complex scenes through them with a variety of settings, mats, geometry etc. Give them a good work-out. I think that's where the energy should be spend right now. If we just do test-scene renders and keep calling for new features, bugs will stay unnoticed. That will slow-down the whole stabilising process.

Now once things have settled a bit, I got nothing against a bit more user-friendliness (as a tech-idiot, remember). The idea of a full documentation is good, especially for anyone coming fresh to Indigo. Things like basic understanding of materials, a little bit like Mike Verta started doing for Maxwell.

I don't know what Ono's plans are, but after the huge step of displacement, I could imagine that he would focus on under-the-bonnet changes, things like memory optimisation, speed, etc. (I just can't think of any must-have features now that we have displacement) This means the documentation may not become obsolete as fast in the future as it has been in the past. That's what I mean with letting things settle a bit.

One last personal thought, and that's really my opinion, is that I'm not too hot on little standalone indigo gadgets. I just can't be bothered to use them. It would be much better from a user's point of view, I think, if improvements were integrated either in the exporters or in the Indigo GUI itself. Imagine, for instance, having the functionalities of Violet integrated in the Indigo GUI, with things like on-the-fly tonemapping or diffraction. This, I think, would take Indigo much closer to the commercial apps than a zillion micro-apps that do just one thing and stop being developed all the time.

The same thing goes for the exporters. I see some exporters, including those that are being written for Luxrender, have interesting features (like the clay render feature for instance). As an Blendigo user, I could imagine a lot of usability and exporter-only features SmartDen could add that would really take Blender-Indigo to the next level. Right now, there's clearly no time for him to do this with all the new features coming in. So again, we're back to the point about letting things settle a bit...

[PureSpider]

+1 BbB

[Stinkie]

Yeah. I agree too.

[Azazeo]

Look, displacement was a major step.

I hope, next will be new sky model ...
And I'll try to get some time to start work at IGS-viewer soon...