Indigo 2.2.2 Beta with new material editor

[remus]

Hmmm, to me the interface didnt strike me as that bad, certainly needs tweaking here and there but i cant see anything fundamentally wrong with it.

[Zom-B]

As far as I remember this is only a technical version to get it working... no GUI design work done atm!!!
After the editor is code safe the GUI design will start...

http://www.indigorenderer.com/forum/vie ... 769#p81769
http://www.indigorenderer.com/forum/vie ... 291#p82291


Anyway... I would still think that a material editor is simply a patch for the aui with Exporter status.
A good exporter is also a good material editor!!!1!!

Since Glare now works together with exporter writers I would say let the guys do something for their money instead of steeling Indigo coding time from Ono ;-)

my 0.02$

[juan_irender]

Well, this is a very delicate matter. The Material Editor is not here as a first aid for Indigo users, I think. It´s a new tool in a preliminary stage.
The fact is that new renderers and tools are appearing in this competitive niche, and Indigo needs to show its powers. Yesterday Mental Ray announced iRay, the GPU accelerated unbiased rendering tool.
I understand Glare Tech efforts, its a small company, but with a very competitive product. Lets Material Editor evolve with no pressure from us. Lets render with Indigo!

Cheers!

[psor]

Please understand me right. The point of a stand alone material editor is, to be independent from
any SDK, from any change the host 3d application will experience. And it has another big advantage,
you need one tutorial for all users for all apps only. No need to cover every application and its own
material system. The plug-in writers don't have to fight to get everything working. It can be such a
hustle to do that. Especially when something in Indigo itself changes. It's horrible to do that for
a coder and it's horrible to do that for every application the company wanna support. Why do ya
think Maxwell has the Studio environment? Of course to make it possible for people to use
Maxwell even their 3d app is not supported.


Marketing and business wise it's perfect to do these things. It has to be done right. That's important.
I haven't said it's crap that Nick wanna have a material editor. I said it is important that it is usable.
It is important that the user feels well if it's being used. When the user wants his host application
material system back then something is wrong with the material editor. Like I said, Next Limit made
big mistakes at the beginning, it's getting better. Random Control was from the start listening to
their users and created a very usable material editor. Like I said, it's not perfect and some people
are missing some things anyway ... I wanted to point out that it is important to have a good
frontend too. Else the people get annoyed and start to weep. And that's bad for business.


So don't think about what you have. Think about what the users need, what they want and make
it even better as they expect. You need an interface designer that knows what he is doing and
that can work hand in hand with the core developer to make everything possible that is needed.


I just try to activate some neurons, cause business is hard and won't make life easier. If you want
a competitive application then you've to look around ya, recognize the mistakes others are doing,
see what else might be needed. There is no need to reinvent the wheel. Designers around the world
are using nature to see how things come together and then use it as base for there design. And then
they just do it. That's the point ... doing it. If you just try, you might fail big times. That's what I like
about Chema from RC, he is listening very carefully and bang it get's implemented after a while. Ian
aka droid (Radium Renderer), amazing how he was doing things in no time. We always where
wondering what is going on.


And you Nick, you've done incredible work on Indigo so far! It was wonderful to see Indigo
evolving over the years. And as you're aware of yourself hating interface design and coding,
I'm sure if you just ask you'll find somebody that will be glad to help ya out. It will make you
and the people around much much happier in the future.


I'm done for today. ;o))







take care
psor

[juan_irender]

Wise words, Psor.
Thanks.

[Jambert]

Psor, you're right it's a very beta realese, final one need to be done by designer. But it's the begining and it allows us to make suggestions step by step. A designer would have create a usefull interface, it's true, but it would be harder to make suggestions out of the way he shoosed... It stay a good start, everybody can make UI suggetions corresponding to his workflow... Could make competition?

[OnoSendai]

I was tweaking with materials and when I bumped on bump I jumped on a issue that has bothering me for quite some time. why pick a unit which you can't even use as bump? For example, if you try to apply a bump of one meter it will be useless, first because in real life there are no such kind of bumps and second because indigo won't cope with it either.
Also while testing the 'clear natural water from the db' I got an error message, while using it on 2.2.1 was fine:

Error: SceneLoaderExcep: Found unexpected element 'start_wavelength'. (In element 'scattering_coefficient_spectrum', around line 17, column 21)

I use metres because Indigo uses SI base units as the standard units, and that means the unit of distance is metres. Are you saying you would prefer it in mm?

[OnoSendai]

would be nice to select folder where material is uploaded

thx

Hi Jambert, do you mean that you would like to be able to pick the filename that the material is uploaded as?

[PureSpider]

I would prefer bump/displacement in mm as one barely needs metre-sized distances for that stuff.
OR keep metres internally and just extend the input field in the material editor window
OR convert the input to metres (input as mm in the editor window)

[pixie]

I was tweaking with materials and when I bumped on bump I jumped on a issue that has bothering me for quite some time. why pick a unit which you can't even use as bump? For example, if you try to apply a bump of one meter it will be useless, first because in real life there are no such kind of bumps and second because indigo won't cope with it either.
Also while testing the 'clear natural water from the db' I got an error message, while using it on 2.2.1 was fine:

Error: SceneLoaderExcep: Found unexpected element 'start_wavelength'. (In element 'scattering_coefficient_spectrum', around line 17, column 21)

I use metres because Indigo uses SI base units as the standard units, and that means the unit of distance is metres. Are you saying you would prefer it in mm?

Pretty much so, SI has their own reason to pick meter as their standard unit, which IMO don't apply on texture bumps (sorry SI unit standard). One of the reasons being clamp issues all over the place (it's way easier to represent 1 meter as 1000 mm then it is to represent 0.001 mm as meters) other being the fact that meter bumps aren't expected nor desired.

[OnoSendai]

I still think creating materials is more intuitive in cindigo but well...

In what way? If you can list specific points I would be happy to work on them.

The connectivity to the matDB is awesome, but would be even cooler for the exporter Plugins, so you could load your material directly into the scene!!
Is there a reason why the name of the creator of the mat for the MatDB isn't shown?

No good reason. The name of the material creator as well as the rating will be shown in future.

More controle for the view of the MatDB would be nice... to choose from categories and browse not only the last 30 mats (maybe having sites with 30 mats each to prevent loading the whole pack of data from the server each time MatDB gets opened!)

Ah yes, category filtering would be useful, especially as the number of materials in the MatDB increases.

The amethyst from the matDB got a error after downloading:

Code: Select all

Error: Error while opening file: Unpack error: Failed to open zip file at 'C:\Users\Zom-B\AppData\Local\Temp\indigo_material_editor_temp_dir\temp_save.pigm'.

Ok, the amethyst zip is probably invalid.

Also why having base_emission and emission... where is the difference?

Base emission is for setting the gross light emission. emission is for applying textures etc..

I also miss the A parameter for textures... B and C is present... but A is lost... also no Texture Exponent to find anywhere!

I hid a and exponent, becuase I don't think the vast majority of users need to use them. Do you disagree?

Are UV type spherical and spherical_environment direct Indigo based projections or just haked for the sphere preview?

They're Indigo projections, mostly used for when creating background materials.

The Sphere model also maybe tiles textures quite too much for the 20cm, but this is maybe impossible to controle...

Yeah.. I might change this preview model, for this reason, also it doesn't show displacement as the sphere is not a mesh.

[OnoSendai]

What I'll say now will sound rude and very impolite and I do apologize in advance.

<rant>

The so called beta of the Material Editor is not beta. It's a construct that is still a
rough sketch of an idea. It is a start. It is unusable to do serious work. And if you
wonder why I'm saying this. Take your time to study how a material editor has
to be. Take a look at your competitors. Take a look of what users are asking
them for. And be serious in what you're doing.


Right now it's more like "ya we need a material editor cause the competitors have one".
Erm, ... have you seen the theirs? They are not the best, but great. If you have no idea
of GUI design, then get somebody who has. If you're a crack with coding a render backend
then do this instead of playing a designer. Usability is more important then the best output.
Take a look at NL's MR. They had o lot of issues with that in the past and still have. RC's fR
is far superior when it comes to usability.


Dang it Nick, you wanna play the commercial game?! Then play after the rules. You're still
playing after the rules of a private project. I know you hate Interface Sh*t and ya no problem
with that. But then holy cow, get someone who has a feeling for it. I promise you, if you
don't realize that you're in need of a good interface designer you'll damage Indigo's image
in a way that will bring harm and people will avoid using it. You know, why using Indigo if
I can use an OSS that is similar.


Please understand me right. I like Indigo. I like the output it generates. I did like your
project for a long time now. I like what you're doing. Please let somebody else take
care of the GUI of the material editor. A good material editor interface takes a lot of
time to develop as every usable interface does. So I beg you, enjoy your math enjoy
the coding you're doing and you love and stay away from the feggn interface, cause
it will kill you cause you hate it.

</rant>



Sorry for the rant! It's just that I do care. You start charging people's hard earned money
and should keep in mind that it comes with a burden. You've to satisfy expectations.
Especially the standards. Just keep in mind, design follows function and yours is, as sad
it is, the opposite. Take it easy, it's just a rant of me caring ... ;o)



take care
Oleg Bogattke aka psor

Hi Psor, as far as satisfying user's expectations go, that's why we've just created a material editor, instead of working on some core features. We did this because a standalone mat editor was maybe the most requested new item.

I think you misunderstand this release. It's a beta release. The point is to gather feedback from users, so that the material editor can be improved. It's not necessarily the final user interface. If you have any specific suggestions, please do write them here. Such a nebulous complaining post really isn't that helpful. The material editor is at an early stage, and I'm looking for constructive feedback, not unhelpful dismissal.

[OnoSendai]

I would prefer bump/displacement in mm as one barely needs metre-sized distances for that stuff.
OR keep metres internally and just extend the input field in the material editor window
OR convert the input to metres (input as mm in the editor window)

Hi Pure, that's definitely true that mm is more common. But have you ever tried to make a mountain range with displacement? It needs more than mm

[pixie]

Hi Pure, that's definitely true that mm is more common. But have you ever tried to make a mountain range with displacement? It needs more than mm :)

Both have distinct purposes, when you set bump standard unit to be mm you're guiding users subliminally into what optimal unit they're expected to be using.

[PureSpider]

Hi Pure, that's definitely true that mm is more common. But have you ever tried to make a mountain range with displacement? It needs more than mm :)

Well then let the user chose and always convert it to metres.
Put another field besides the input one where you can chose the unit you'd like to use.