Does it possible to adapt the script "arrow key rotation 3D view" to a selection? :)

When nothing is selected the 3Dview is rotated with the arrow key
When something is selected the selection is rotated with the arrow key (useful in any view!)
/ by the center of gravity of the selection (or by an another point) ?

I suppose yes, but I am some rusted for this little brain sport ;)
Maybe enter somewhere a numeric angle rotation will be also useful
actually 6° can't make 10° :)

> When nothing is selected the 3Dview is rotated with the arrow key
> When something is selected the selection is rotated with the arrow key
> (useful in any view!)
> / by the center of gravity of the selection (or by an another point) ?

Hi Pilou, currently I don't think there is a way to do this since there isn't a way for a script to get the center of gravity of the selection right now. I can add this at some point in the future but I don't think this will be ready for V1.


> Maybe enter somewhere a numeric angle rotation will be also useful
> actually 6° can't make 10° :)

Well, if you requie a 10 degree rotation you can alter that script to have a 5 degree or 10 degree rotation instead of 6 degrees.

Is there something that you're doing that requires an exact 10 degree view rotation?

- Michael

Re: C4D

Well, it can't just be an accident that C4D uses the good normals to start with - that means they have some support for vertex normals in there.

The problem is that pre-defined vertex normals don't really work well with further point manipulation. If you select a point of the model and drag it to a new location, the vertex normals need to be changed as well.

It is understandable that during that type of an edit that the "good normals" would be eliminated and other ones created by averaging polygon faces.

However, this is not the case for a "flip" edit - in the case of doing a direction flip it is possible to preserve all the normals and just flip their directions as well.

The problem is that C4D apparently treats a "flip" edit the same as a "drag point" edit.

If Steph could request to them to not destroy the existing normals on a "flip" edit, that would be a nice improvement to C4D.

- Michael

>10°
Nothing special in 3D view, only if arrow keys can works for a "selection"
In this case any angle will be possible :)

Despite the fact of this C4D bug seems other 3D prog have same problem !
hexagon, Subdo...
So a very cool thing will be in Moi in the OBJ export mode
all faces/normal "back to camera" in blue color : just click over for inverse it !
here in Subdo

While we are on the subject of the obj exporter I would like to suggest that the user be able to select whether to export to a Y up or Z up coordinate space. Right-handed or Left-handed coordinate space? For now I sometimes need to rotate the whole object before or after the export, depending on which app I am exporting to, which I admit is not a major step.

Sorry if this has already been requested.

> Despite the fact of this C4D bug seems other 3D prog have same problem !
> hexagon, Subdo...

Hi Pilou, well normally it is not a terrible problem since all those programs provide a method for reversing the normals for a mesh.

I'm not familiar with Subdo, does it have no "flip" capability in it?

If it has a flip function, then use the flip function and your problem will be resolved.

Also if you are doing double-sided rendering, then it does not matter which direction the normals are pointing.


> So a very cool thing will be in Moi in the OBJ export mode
> all faces/normal "back to camera" in blue color : just click over for inverse it !
> here in Subdo

Hmmm, well if the normal direction did not matter to you, it would be rather strange to have some surfaces appear in blue, it could easily cause someone to think "I wonder what is wrong with that surface, why does it look different", when for their purposes nothing was actually wrong with it at all.

But I could see possibly doing this as an additional option, something like a "show normals" checkbox in the advanced section.


> just click over for inverse it !

Well, stuff like this doesn't just happen automatically, I will have to add additional code to handle clicking on mesh objects, I don't currently have a provision for this.

I'm getting very close to the end of development for version 1.0, so I am trying pretty hard to reduce the amount of brand new work that I'm doing for a while. So I'm not sure if I will get this into version 1.0 or not.

- Michael

> While we are on the subject of the obj exporter I would like to
> suggest that the user be able to select whether to export to a Y
> up or Z up coordinate space.

Hi Joe, there is an option for this but it is currently only settable in the moi.ini file -
[OBJ Export]
SwapAxes=y

If you turn SwapAxes=n there, then it will export to a z-up coordinate space.

I do plan on making that setting available in the Settings dialog, once I get a chance to overhaul the settings UI.

- Michael

Great news, thanks!

I say blue for be in design with the prog, sure Red is more informative and preventive :)

> I say blue for be in design with the prog, sure Red is more informative and preventive :)

Well, red is often times used as a type of warning. That's great if you are expecting a warning.

But if you don't know what it is that you are being warned about, or if the warning does not apply to you, then it can be confusing to see a warning... I really want to try to minimize this type of "confusion feeling" as much as possible.

That's why I would probably put it as an optional thing that you could turn on, rather than just showing some red surfaces to people by default.

- Michael

Suggestion of more effective ergonomy by Steph :)
(on the right :) maybe more efficient than slot

Double side are not good in the optic of the real time render engine :)

Subdo has culling http://www.vb2s.com/download/videos/subdo/culling_tools/culling_tools.html
(adjust normals)

Hi Pilou, I can understand why he wants it that way, but it is not practical for me to do that by default for several reasons.

First, the text is so small for many of the icons on the bottom as to be unreadable. For example, I need to approach very close to the screen to read the text for "separate" in that screen.

For text to be useful it has to be of a certain legible size. That means that the buttons need to be generally fairly larger than what he has shown in this example.

Larger buttons also require more space - to have legible button text means that the number of buttons that he shows here would not fit on a 1280x1024 screen (let alone a 1024x768 one).

User interface design is a very tricky thing. I would be a lot more free to do a design like this if made MoI only run on a 1600x1200 resolution screen, but there are a lot of people that don't have that high of a screen resolution. I want MoI to work well for people who also have lower resolution screens instead of only being a specialized tool that requires specific hardware.


The other major problem is scalability. By which I mean the ability to add more functionality in the future. If I completely fill up the screen with all available tools now, then that makes it difficult for me to add functionality in the future because there would be nowhere to put it! One big reason for the current tabbed design is that it includes scalability built in, since not all the tools are displayed simultaneously. This will make it easier for me to add additional functionality in the future.


At some point in the future I would like to make the UI more easily configurable so that you could have some control over it. However, I decided for V1 to put my effort into making an easy to use default UI instead of putting a lot of effort into making it easily customizable (by drag/drop, etc... - it is actually possible to modify it right now if you editing the HTML UI code).


If I had the luxury of designing the UI for a specific resolution and without the need for future expansion, the it would be possible to do as he suggests. But these are important limitations that I have had to work within.

A lot of UI design is about compromise, because if you optimize a whole lot for just one person, it can be detrimental to a large number of other people.

I appreciate the suggestion though!

- Michael

> Subdo has culling http://www.vb2s.com/download/videos/subdo/culling_tools/culling_tools.html
> (adjust normals)

Then doesn't using that tool solve the problem?

I guess I don't understand why Subdo was brought up - is there a problem that can't be solved with bringing objects into Subdo, or does using that tool above fix the problem?

I can understand that it is convenient to have control over this at export time, but I don't understand why this is being described as such a major problem with different applications, like Subdo for example.

- Michael

Yes I know the problem of Size text, icone, resolution, size screen ... :)

Steph see the interface in the optic of professional productivity not for the point of view of beginner user !)

No Subdo was just used for test the Moi export result as any other 3D prog

In fact he want to find the less operations to make between Moi export and the input in the 3D real time engine

> Steph see the interface in the optic of professional productivity not
> for the point of view of beginner user !)

Certainly. But not all of these considerations are only for the benefit of beginners. For example having a good plan for future expansion of the UI is of good value to professionals.

Some other things such as large buttons are easier to click both for professionals and beginners alike.

- Michael