Hi vodkamartini,

> I think using light definitions to auto generate the
> cubemap is rather limiting

Not really - it actually gives me a lot of freedom to just adjust a few parameters and then generate several variations on a basic structure.

Like for instance I may be able to have one version with the key light stronger and the fill lights lessened, one with no fill lights, and one somewhere in between.

It's also possible for me to adjust the key light direction dynamically since I'm generating all the data.

Much of this flexibility would not be so easy to handle (or probably not possible for changing of directions) if it were only based strictly on static pre-generated maps.


> These days it's trivial to just jump into 3ds max, maya,
> modo, etc. and generate environment maps that work better.

There are many MoI users who don't have any of those applications, so it is not really so great to be totally dependent on that method.

I think that will be great as an option in the future, but having procedurally generated ones is much more practical for the initial base functionality.

- Michael

I only meant it was limiting from the user's perspective (in that we can generate the same env. maps in a 3d package, plus much much more). I completely understand the advantages on your end, especially if you're dynamically updating the lights. I'm sure many people would be eager to produce and share their own maps, so I doubt those without the necessary 3d packages wouldn't stand to benefit.

You're right about the examples DesuDeus posted as being too aesthetic. I think a happy medium between pure eye candy and bland functionality can exist, with more of the interesting solutions achievable outside the confines of simple omni/directional/spot lights. I also agree that what you have now is a proper foundation, and I never meant to suggest replacing it - merely supplementing it.

Anyway, I like the improvements you're making and I'm sure I'll enjoy whatever look v2 ends up having. Keep up the great work!

Looking good Michael, where are you heading with this, are you just experimenting or are you implementing these visual options in V2 ?

Cheers

Hi Danny, well I was just doing some quick experimenting with some different things I can do now with the new lighting mechanism, and I just kind of happened to find that metallic look is easy for me to do now with it.

I actually tweaked just one line of code to get it, I was just thinking hmm I wonder what will happen if I do this instead and out popped that look.

So yes, I think unless something goes unexpectedly wrong I'll be able to include it as an option in v2.

This technique should work fine with old cards too, all the way back to the first GeForce or Radeon cards. I just did a quick test on an old GeForce2 and a Radeon 7500 and it is looking good there...

- Michael

@Michael

> "Having some more compressed gradients actually helps to give a bit more prominent visible reflection lines,
which are kind of what you want to look for when you are using the reflection as a guide for surface smoothness."

I disagree, there's Zebra for surface smoothness. Or checkerboard.

> "The blurry one that you show reduces the effectiveness of using reflections for that purpose."

Well the blurry one is only for beauty, its good to work on good looking models. You said that dark UI are depressing, I say that
grey models are depressing too :)

> "I'm not only shooting for just a purely aesthetic result with this function, I'm also trying to give it some practical qualities as well."

I understand that, but if you look for pratical then Zebra and also one wich has very light shadows, would be more practical than metal.
But if you want to do both aesthetic and pratical made 1 zebra, 1 chrome, 1 blurred.

> "Your comments seem to be putting a kind of "final rendering" aesthetic look above all else which is
not necessarily the right direction for a kind of interactive modeling mode, really."

Yes but I never show anything else that "renders" to the clients, so that aesthetic is only for my personal use.

> "I can understand the desire to make things look really cool, but also you seem to have a tendency
to want to place "form over function", which is not really the philosophy that is guiding MoI in general."

I agree on this one, I like the form im 200% a graphic and design guy. But I think that MoI as already too much function over form.
MoI website says "MoI, 3D Modeling for Designers and Artists" I think that designers need
good looking env maps (auxpecker author is a product designer in china)
The "Artists" part is already mission complete because MoI is simple and powerfull so Artists can work on MoI.

> "There are many MoI users who don't have any of those applications, so it is not really so great to be totally dependent on that method."

I disagree on this one, if you implement .jpeg or .png env maps I would make literraly tons of them and share them for free on MoI forum!
And I would share them because as you said "not everyone have those applications" so I would take time to help people who dont have the software.
If you allow users to make content they would be very happy to produce content because they all love MoI.
That's also why I make comments and requests, that's because I cant help you coding MoI because im not a code guy, but I still want to do something because I cant work on any other software for modelling since ive discovered MoI 3d :)
Oh and ive posted my WiP on Nurbs + Poly forum, one guy commented "i never get my hands on Moi but defently have a look at it and some nurbs stuff."
and the other one said "I find it kind of interesting that you find NURBS to be easier.
I'm the other way around. Of course, i started out with box modeling and am trying to learn NURBS on the side."

Ive told them to visit MoI website and download the trial version :)
Keep up the good work, if you think my critics are rough tell me, im not trying to be annoying. I only want to give the better feedback I can.
And I understand that everyone as a different workflow, some people doesn't need and know what are environement maps.

>I agree on this one, I like the form im 200% a graphic and design guy. But I think that MoI as already too much function over form.
>MoI website says "MoI, 3D Modeling for Designers and Artists" I think that designers need
>good looking env maps (auxpecker author is a product designer in china)
>The "Artists" part is already mission complete because MoI is simple and powerfull so Artists can work on MoI.

Not my place but I TOTALLY disagree...

How is the sweep tool working for you? Do you really think materials, environment setting are more important for designers than tools like surface editing, dimensioning tools etc.?

QUOTE.
(There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. —C.A.R. Hoare)

MoI as it stand now it does fall in the first category BUT it could go the "Rhino way" (if we not careful what we wish/demand) Look Rhino V4 for example, is a Bloatware IMO...The developers Instead on focusing how to improve the Boolean tools they come up with Real Time shadows...Instead of improving the import/export file formats...they develop the nXt render engine. Not to mention the other animals in the jungle :)
The bottom line is Rhino could have been the best Modeler out there BUT...

Anyway I hope MoI develops to a KICK ASS Specialized Tool...Nothing Less Nothing More.

Hi DesuDeus,

> I disagree, there's Zebra for surface smoothness. Or checkerboard.

Those are great for doing a kind of special check, but they are so overwhelming on the screen that it is not very convenient to use those styles for full time regular modeling.


> I understand that, but if you look for pratical then Zebra and
> also one wich has very light shadows, would be more practical
> than metal.

No, although Zebra is good to have as well, but it is not as practical as the metal one I showed previously for having on full time while modeling.


> MoI website says "MoI, 3D Modeling for Designers and Artists"

Yes - notice that it says 3D Modeling for Designers and Artists, not 3D "Rendering" for Designers and Artists.

Currently MoI is focused on being a tool for modeling, that's why many of the current priorities are oriented towards practical functions and ease of use and not necessarily for just having the most possible beautiful image on the screen like it would be when you are working on producing renderings.

For a tool, the priority is usefulness first. If there is some choice that makes a more cool looking screen image but negatively impacts usefulness, then that would not be aligned with MoI's current goals.


Don't get me wrong, I'm not opposed to having things look nice when possible as well, but that is a lower priority goal. Despite that, I actually have spent a lot more time improving the graphic look of MoI than I had done in previous projects like Rhino for example.


> The "Artists" part is already mission complete because MoI is
> simple and powerfull so Artists can work on MoI.

No, I don't think that will ever really be "mission complete"... There's still a lot more ground to be covered in the "modeling" part.


> If you allow users to make content they would be very
> happy to produce content because they all love MoI.

Yes, this would definitely be a useful function to be able to include user-generated environments, and I do want to include it in the future.


> if you think my critics are rough tell me

It's not that they are rough, they sound like cool and fun things to do definitely!

But your priorities (for example, just making things "look cool") are not in line with MoI's current development priorities - that means that I can't easily act directly on your feedback so much in the short term because it would take me away from the current set of goals instead of moving in line with the current set of goals.

- Michael

Neo - As far as I know, there is one guy working on real time shadows and he has nothing to do with making improvements to the Boolean code. Just as the people who build Accurender/Flamingo/nXt may not be the people who handle updates to the file I/O. I dont know for sure but it's a pretty fair assumption that development would be compartmentalized.... Also I wonder which I/O you are referring to? Because I don't see many complaints about improving the exporters. I only see a lot of complaints to improve the mesher. And that is easy to agree on! :P

Some more tweaking and refining.

I think there will be a few choices for some different combinations of intensities of the fill lights. This one has them up pretty high, maybe this will be about the brightest:



The same intensities with "metallic" option:



- Michael

@Neo

> "Anyway I hope MoI develops to a KICK ASS Specialized Tool...Nothing Less Nothing More."

Specialized? I think most people buy MoI because it has a powerfull UI and its simple... not "specialized"
I hope MoI become more and more simple and powerfull, not become an elite specialized tool like Rhino.

> "How is the sweep tool working for you?"

It does exactly what I want already.

> "MoI as it stand now it does fall in the first category BUT it could go the "Rhino way"

I dont want MoI to go to the Rhino way, env maps are in the first category because it makes simple to model things, its an help for modelling.



@Michael

> "No, although Zebra is good to have as well, but it is not as practical as the metal one I showed previously for having on full time while modeling."

I dont use Zebra, I never used it, only discovered it in Rhino. If im asking for Zebra its not for me, its for people who need to check for continuity.
I never do class A surfaces and I never care about G1, G2 and G3. I agree that its not as practical as the metal one, its a specialized tool so it cant be good for full time modeling.
By the way Zebra can be good looking too (Alias design screenshot)

> "Currently MoI is focused on being a tool for modeling, that's why many of the current priorities are oriented towards practical functions
and ease of use and not necessarily for just having the most possible beautiful image on the screen like it would be when you are working on producing renderings."

Well I think that env maps improve modelling ease and comfort. And as I said to Neo I dont want to use MoI as a product rendering.

> "For a tool, the priority is usefulness first."

You are currently working on a new light system, it can be both usefull and good looking.

> "But your priorities (for example, just making things "look cool") are not in line with MoI's current development priorities
that means that I can't easily act directly on your feedback so much in the short term because it would take me away from the current set of goals instead of moving in line with the current set of goals."

Yes I agree, but I see that you are currently working on that light system so I speak only about that particular area. If it was a thread about the modelling tools I will only speak about modelling tools and making feedback about them. And its not "my priorities" I dont have priorities I found MoI to be already perfect for what I do. Im not a product designer also. Its just that I like to give feedback on anything.

> "Some more tweaking and refining."

This one is perfect! No more dark areas :) This is very usefull.

> "The same intensities with "metallic" option"

Very good looking too, much better than before. The sphere is kinda strange but the Squid thing is good.

Michael,
Have you already an idea of where the lighting will be implemented and in what way?

It appears to be a style? some objects can have this and others can be normal style? Not just a viewport implementation?

Hi Burr - no for now at least it won't be able to be set on a per-object basis, it's a global setting that controls everything in the viewports.

Maybe in the future it can get set by style, but that could possibly have some performance difficulties.

I'm kind of getting an idea of where this will go in the UI, probably there will be some stuff in Options / View to control the default light setup, I should be digging into that pretty soon here.

- Michael

God man, DIG! I dont know if the dilithium crystals can take much more!

>Specialized? I think most people buy MoI because it has a powerfull UI and its simple... not "specialized"
>I hope MoI become more and more simple and powerfull, not become an elite specialized tool like Rhino.

Last think I would call Rhino is "elite specialized tool"...on the other hand Alias Surface is what you call "elite specialized tool"

>I dont use Zebra, I never used it, only discovered it in Rhino. If im asking for Zebra its not for me, its for people who need to check for continuity.
>I never do class A surfaces and I never care about G1, G2 and G3. I agree that its not as practical as the metal one, its a specialized tool so it cant be good for full time modeling.
>By the way Zebra can be good looking too (Alias design screenshot)

I see...But you understand class A surfaces etc. is what DESIGNER demand/dream from a Nurbs app. like MoI. Anyway even if you are a Visual artist if those rules not applied The outcome will not be "smooth"...Seams will be visible even were you have applied simple fillets...BUT I'm sure you know all that already :)
Is also ironic you show an Show an alias zebra screenshot and not a Rhino one :)

Yeah because I found Rhino one uglier aha :D
Alias one is a mix of lighthing and zebra, I found it very cool looking.

"But you understand class A surfaces etc"

Yeah I read a lot about 3d in production, films etc... Im a geek :)

I know Jonah But those developers get paid and I think most people who invest to Rhino is for the Modeling tools...That's where their main focus should be IMO.

file I/O...Here is funny example, Rhino to SolidWorks. Last time I tried SW would not read a simple surface coming from Rhino...The remedy, Open .3DM in MoI re-save and VOILA it now opens in SW.

BUT I'm OFFTOPIC here, so lets use pm if necessary :)

> I'm kind of getting an idea of where this will go
> in the UI, probably there will be some stuff in
> Options / View to control the default light setup,
> I should be digging into that pretty soon here.

As in a place to alter the light parameters (ala Rhino) or as a simple combobox to choose between "diffuse" and "metallic"? If you made the light parameters accessible via the javascript interface I can imagine someone creating a plugin where a dialog window pops up with preview icons allowing users to easily select different custom lighting schemes.

Hi vodkamartini,

> As in a place to alter the light parameters (ala Rhino) or as
> a simple combobox to choose between "diffuse" and "metallic"?

I think probably a bit of a mixture.

The current thing I'm thinking of would be to have a combo box which would control a few predefined choices for intensities, something like:

Default key + fill lights
Key + more fill
Key + less fill
Key light only
Custom key + fill levels
Hemispheric

Then a checkbox for "Metallic", and another checkbox for "Specular highlights".

For a couple of choices (Custom key + fill levels and Specular highlights) there would be some additional slider controls that would pop up to allow some fine tuning. (note that this may be one of the benefits of having procedural generation that I was talking about previously).


But I'm still not quite sure yet, I am nearly ready to see if the ideas for this will work or not.


It looks like one remaining overall problem is that with intensities set up that make colorized surfaces look good, regular white models look rather too bright, almost cell shaded.


> If you made the light parameters accessible via the javascript
> interface I can imagine someone creating a plugin where a dialog
> window pops up with preview icons allowing users to easily select
> different custom lighting schemes.

I don't know... right now they're specified numerically by a bunch of angular rotations, and I don't really think you're going to get a lot of control for significantly different variations without more detailed control over the number of lights, intensities of each of them, etc... rather than just altering the angles of the existing ones.

That would end up being a pretty in depth script interface to control all the details.

It seems like it would be better to focus on supporting reading in image maps (in the future) for getting customized lighting schemes instead of that.

- Michael

Gotcha. I like the variety of options you're planning, and it sounds like you're trying to make it more user friendly than Rhino's vector + diffuse + spec inputs.




In terms of a scripting interface, my first thought would have been to just accept an array of light objects that you can loop through. So javascript-wise the above rhino settings might look something like:

lights = [];
lights[0] = {
    direction: {x: 1, y: 0.8, z: -0.5},
    color: {r: 214, g: 214, b: 214},
    spec: {r: 146, g: 146, b: 146}
};
lights[1] = {
    direction: {x: -1, y: -0.5, z: 0},
    color: {r: 0, g: 0, b: 0},
    spec: {r: 115, g: 115, b: 115}
};
lights[2] = {
    direction: {x: -1, y: -0.8, z: 0.5},
    color: {r: 100, g: 100, b: 100},
    spec: {r: 0, g: 0, b: 0}
};
moi.lightingEngine.setLights(lights);

Of course your lights might have different properties than Rhino's depending on the types you allow (point, directional, spot, etc). Anyway, it's not a big deal in the end. I was just tossing out an idea since you were working in that area.

Hi vodkamartini,

> and it sounds like you're trying to make it more user
> friendly than Rhino's vector + diffuse + spec inputs.

Yes, definitely! The one that you show there is kind of a disaster as far as usability is concerned.

You actually could not even do the one I'm currently messing with in MoI there because it's made up of 12 lights - 1 key light, then 10 low intensity fill lights distributed evenly between 2 locations, and then one additional fill.

It can help a lot to have some distributed ranges of lights, and it's not so convenient to try and manage a bunch of those individually listed in a dialog.

What I'm hoping to do is to have 2 sliders which you can adjust, one for the intensity of the key light, and another for the combined intensity of the 11 fill lights. But I have not got that quite set up yet.

The current script interface for setting the light direction (moi.view.lightDirection) still works to set the direction of the key light and the fill lights will move relative to it when it is altered.

- Michael