Indigo is great, but...
- daniel_nieto
- Posts: 173
- Joined: Wed Apr 11, 2007 10:45 am
- Location: Ciudad Guzman, Jalisco, México
- Contact:
i've always thought that people thinks the more expensive the better result they got, and it applies to everything you want, iPod for example, they are expensive, and they are great ok, but there are several, not to well known companies who makes their own devices which costs much less than an iPod, and equals the quality...
you can compare linux against windows, why do most of the companies not emigrate to linux? cause they are selling something, and they dont trust on free software, they think, if something (windows) cost me half of my testicle, it surely wont let me down...
another analogy, is blender vs 3dsmax ... the same thing happens here...
i was just adding my opinion about, why indigo isnt that popular or used by big companies...
you can compare linux against windows, why do most of the companies not emigrate to linux? cause they are selling something, and they dont trust on free software, they think, if something (windows) cost me half of my testicle, it surely wont let me down...
another analogy, is blender vs 3dsmax ... the same thing happens here...
i was just adding my opinion about, why indigo isnt that popular or used by big companies...

I think the lack of "easy to use" comes from the way these programs work. They are separate programs that need exporters to take data out of the users 3D program and convert it to the render software code. I don't know how easy this can be. And an attempt to make it easy takes a lot of time that developers like me do not have anymore. This work requires knowledge of Indigo and its scene code, 3D program and its API code, and some level of computer programming education to put it all together.
By adding up research time, preparations, testing, trying to make easy to use, publishing, then fixing any bugs.......all related to one new build. This takes an enormous amount of time. Usually this resulted in me doing updates and then never using my own published files because I was burned out from putting it all together. If you are like me, I did it for fun....but now I have no more time to allow. I would like to allow any time that should come up in the future, to make a scene of my own.
By adding up research time, preparations, testing, trying to make easy to use, publishing, then fixing any bugs.......all related to one new build. This takes an enormous amount of time. Usually this resulted in me doing updates and then never using my own published files because I was burned out from putting it all together. If you are like me, I did it for fun....but now I have no more time to allow. I would like to allow any time that should come up in the future, to make a scene of my own.

Content contained in my posts is for informational purposes only and is used at your own risk.
The idea adding a wiki-section to the forums is quite nice and i welcome it. i never ever worked on a wiki before but i will try to get into it.
we need more such proposals and not the discussion whether it is good or not to develop some usability-features. we as the users should produce some more materials or we could make some contests every now and then to fill the material- DB =)
greetz
we need more such proposals and not the discussion whether it is good or not to develop some usability-features. we as the users should produce some more materials or we could make some contests every now and then to fill the material- DB =)
greetz
I'm actually with Labello on this one. Right from the beginning when I started to script Max exporter I used native 3ds Max terms. I used "Diffuse Map" instead of "Albedo" and stuff like that, since this is what it is called in Max. I think making it more easy to understand doesn't require much extra time at all.. just some common sence. If your host app has a sertain vocabulary, then the exporter shoud stick with it as much as it is possible. User doesn't care how things are named inside Indigo. He wants to use it as an external renderer for his app. That's it. He doesn't want to learn a new "language" (if you know what i mean).
Mmm well I don't know... MayatoIndigo uses indigo's params names. I didn't code it but I defended that way of implementation.
In my mind the user should certainly not have to learn a third application, that is, the exporter, but he/she is supposed to know both it's 3d app and Indigo.
Reducing this to the 3d box only represents a step toward vulgarisation wich I don't support much. Though I understand the benefits of it.
In my mind the user should certainly not have to learn a third application, that is, the exporter, but he/she is supposed to know both it's 3d app and Indigo.
Reducing this to the 3d box only represents a step toward vulgarisation wich I don't support much. Though I understand the benefits of it.
obsolete asset
So its like you have used your app for years and have been calling the diffuse map well.. "diffuse map"
and now you should suddenly start using a term called "albedo" which is actually the same old diffuse map
? And only because inside of a renderer it is called like that?
We are talking about a shorter learning curve here and user friendliness. I think a good exporter should blend with the host app as seamlessly as possible and offer as fiew new parameters as possible.
BUT I see one reason why to use the same parameter names as Indigo has. It is the online forum and the community where most of the talk is using the Indigo terms. It could get a bit confusing, when people in forum are talking about "albedo" and a user can't find it from the exporter. Now you cant have both obviously, so it's either one or another way.
One way to overcome this would be a good manual for the exporter and that sure would be very time consuming to write.


We are talking about a shorter learning curve here and user friendliness. I think a good exporter should blend with the host app as seamlessly as possible and offer as fiew new parameters as possible.
BUT I see one reason why to use the same parameter names as Indigo has. It is the online forum and the community where most of the talk is using the Indigo terms. It could get a bit confusing, when people in forum are talking about "albedo" and a user can't find it from the exporter. Now you cant have both obviously, so it's either one or another way.
One way to overcome this would be a good manual for the exporter and that sure would be very time consuming to write.
Hold on Labello, Rome wasn't build in one day ! You are taken seriously, kram must just pop in every thread, almost like me ^^
Well maybe the exporters can have a switch between host and Indigo vocabulary. That should not be so much work for exporters devs to redefine labels if switch is on, much less than writing a full doc IMO.
No rush, there is always a huge inertia in forums (disponibility etc) but there are always people hearing you, too
Well maybe the exporters can have a switch between host and Indigo vocabulary. That should not be so much work for exporters devs to redefine labels if switch is on, much less than writing a full doc IMO.
No rush, there is always a huge inertia in forums (disponibility etc) but there are always people hearing you, too

obsolete asset
Who is online
Users browsing this forum: No registered users and 8 guests