OBJ export will not create MTL file

[Gavin]

"deepened menu hierarchy with far more mouse clicks for often used functions": The main menu of v6 and v7 are pretty identical. Only the context menus of the 3D view have been redesigned to make them more uniform between the editing modes and therefore more predictable. This change is based on user requests and we once had quite lengthly discussion about the design of the old context menus here in the forum. They also contain way more tools now which required some sort of hierarchical organisation. I can't remember any complains about that feature so far.

Apple's user interface guidelines for contextual menus says:

Include only the most commonly used commands that are appropriate in the current context. For example, in the contextual menu for selected text, it makes sense to include editing commands but it doesn’t make sense to include a Save or Print command.

In the 6.x context menus the Polygon editing options would be at the top level when I select a model for editing readily available and applicable to the selection I made.

If you look at the 7.x menu there is a large number of items that are both completely irrelevant to my selection, in addition to these menu items being active although they have nothing to do with the current context.

What you essentially have done is duplicating a good section of the main menu in the context menu, thereby forcing the user to navigate one level deeper to get to the relevant menu item. The result is a lot more mouse movements to get to the same command + it makes you memorize you have to select Polygon to perform, say a Ring Cut, rather than it being readily available on the top level of the context menu.

This makes the application less fluid to use, and it force the user to memorize more of the menu structure making it harder to master for new users. This is also typically how we see menus constructed in Windows and Linux based applications. Copying that behavior is not a good idea on macOS.

 

[Gavin]

"changed interaction between the UV map and polygon selection that requires additional pane activation and subsequent deactivation": I'm sorry but I'm not sure what you mean with that. More details welcomed (please open new bug)

In the image below you can see a mesh that has 3 materials mapped to different sections of the mesh, but projected into the same UV surface. It makes for a horribly cluttered UV map to work with.

If you zoomed in to the UV map or the model you might see that parts of the model is very dense (and this is a low poly model so it can be MUCH worse.)
Sometimes you need to adjust the geometry or delete geometry from such an object but making selections on the model itself can be particularly tough of the geometry is inside or small. In this case it can often be much faster to make the selection in the UV map as you see on the screenshot.

In 6.x geometry selected in the UV map could always be deleted from the model just by hitting the macOS Backspace key regardless if you had the Select tool or the Move, Scale, Rotate tool active , but in 7.3 it is never consistent if you can delete the geometry or not. Sometimes it just beeps regardless of what you do and the UV window must be closed and you can try again. Other times it will work if the Select tool is active, other times not.

Perhaps you tried protecting the user from inadvertently deleting geometry when in the UV editor, but the ability to do so was of great help when working on complex models or for fast cleaning up an existing model where you only wanted to reuse parts of it as the base for a new one.

 

[Gavin]

"unfixed bugs in vertex weight painting": I also have no open bug report about a problem in the vertex weight tool. I have no idea what you mean. More details welcomed (please open new bug)

When you heat map or distance map a model it might weight vertexes that it should not be influenced by a joint. The subtract brush will usually let you clear out the mapping, but at times it simply stops working and you have to start over again. I have not found any use pattern that can repro the issue. The same issue existed in 6.x too.

 

[Gavin]

"lacking stacking of uvs without adding a baker." That functionality is there since a long time. Just use the "Selection->Automatic seams" command followed by "Unwrap UV with LSCM". The button in the Baking tag is a pure convenience features to save some clicks. In the background it just perform these two tools plus some scaling. With Hotkeys you can mimic that functionality with two key strokes.

That is not what I am talking about...

Say you have in your library two different models where you want to reuse parts of both in a combined new model and in addition adding new geometry.

What you most likely will have is unwrapped uv for the two old models but they are scattered in different places and may even be overlapping. In addition you have new geometry that has yet to be unwrapped.

One trick to pack all the UVs inside the texture area is to add a baker to the model and it will unwrap and collect all geometry inside that area. Other 3D apps have such functionality with a menu command that effectively does the same.

Sometimes unwrap with LSCM will do the job as you say, but at times it creates horribly bad UV maps rotated in all kinds of directions and not scaled very well. Unwrapping with ABF as an alternative works great at times, at other times horribly.

Using automatic seams have a tendency to not produce the desired result without quite a bit of adjustments.

 

[Martin]

Apple's user interface guidelines for contextual menus says:

Include only the most commonly used commands that are appropriate in the current context. For example, in the contextual menu for selected text, it makes sense to include editing commands but it doesn’t make sense to include a Save or Print command.

In the 6.x context menus the Polygon editing options would be at the top level when I select a model for editing readily available and applicable to the selection I made.

If you look at the 7.x menu there is a large number of items that are both completely irrelevant to my selection, in addition to these menu items being active although they have nothing to do with the current context.

What you essentially have done is duplicating a good section of the main menu in the context menu, thereby forcing the user to navigate one level deeper to get to the relevant menu item. The result is a lot more mouse movements to get to the same command + it makes you memorize you have to select Polygon to perform, say a Ring Cut, rather than it being readily available on the top level of the context menu.

This makes the application less fluid to use, and it force the user to memorize more of the menu structure making it harder to master for new users. This is also typically how we see menus constructed in Windows and Linux based applications. Copying that behavior is not a good idea on macOS.

The first things that pops into my eyes is that you use almost no hotkeys. That makes your workflow extremely slow of course. Especially the most commonly used polygon tools should be assigned to hotkeys. Once you use hotkeys for these tools the workflow will be much faster. No matter if you use v6 or v7.

Having one level of submenus is totally fine if you ask me. Just look at Mail, XCode, Text Edit, etc. which all have one level of submenus. So that should be no violation of the Human Interface Guidelines.

I'm also pretty sure that one commonly used context menu for all modes is way easier to mesmerise than multiple different.

It's always possible to discuss UI decisions extensively since UIs are always very subjective and I'm 100% that it is not possible to make everybody happy but so far the new menu structure was received positively.

I have doubts if it is worth delaying new 3D features because of a redesign of the context menus.

Please give hotkeys a chance.

Bye
Martin

P.S. Screenshots of Mail and XCode attached.

 

[Martin]

One trick to pack all the UVs inside the texture area is to add a baker to the model and it will unwrap and collect all geometry inside that area. Other 3D apps have such functionality with a menu command that effectively does the same.

Do you have a link to that tool. I'm still not 100% if I understand you right.

 

[Martin]

When you heat map or distance map a model it might weight vertexes that it should not be influenced by a joint. The subtract brush will usually let you clear out the mapping, but at times it simply stops working and you have to start over again. I have not found any use pattern that can repro the issue. The same issue existed in 6.x too.

That's strange. Should you figure out how to recreate the problem please let me know.

I actually planed to completely rewrite the vertex weight tool for v7 but at the end it dropped form the list. I hope that I will find some time in the not so distant future.

Bye
Martin

 

[Martin]

That depends if the receiving app is able to handle the units. Many applications assume the unit to be in meter.

In Cheetah 6.x a DAE document for a rigged mesh would have in the file:

<unit meter="1.0" name="meter"/>

and when imported into DAZ studio or OpenSim/SecondLife viewers have the (real world) units 0.396 X 0.975 X 0.586 (see attachment)

For Cheetah 7.x the DAE document has with the default export settings

unit name="centimeter" meter="0.01"/>

and when imported into DAZ studio or OpenSim/SecondLife viewers have the (real world) units 0.00396 X 0.00975 X 0.00586 (see attachment)

which have to be manually scaled up adding the 100 multiplier on import to be
(real world) units 0.396 X 0.975 X 0.586 ( see attachment)

You can say this is all good and dandy as you can compensate with setting the Export multiplier to 100 in the Cheetah export preferences for the file type, and this works fine for unrigged objects.

However, if you try to do the same for rigged objects it throws off the vertex mapping completely on import unless you set the Cheetah multiplier to 0,01 and then multiply by 100 on import. – The result being you have to manipulate the multipliers depending on if the model is rigged or not. This adds additional steps that can easily be forgotten in an adjust, export, import, test cycle which you do tons of with rigged and vertex mapped models.

You can say the above is non-standard behavior per spec, and it probably is, but the problem is that these tools are often programmed to the Maya -> Autodesk FBX 2013 converter -> your tool chain behavior.

To avoid this it would possibly be better if the 1.0 DAE export multiplier meant 1 meter as it did in version 6.x. That would also be consistent with an approach of a Cheetah 1x1x1 cube to represent a real world dimension of 1x1x1 meter when you model for real world scaling.

The DAE workflow is very difficult since it requires tons of testing to find a configuration which works well for most apps.

Cheetah3D DAE files should be 100% Collada spec conform but that doesn't guarantee that all apps load it properly. Writing a 100% spec conform importer is such difficult that it probably still doesn't exists. At least I haven't seen one yet.

For apps supporting FBX I strongly recommend to use FBX. For apps like XCode Collada is the first choice. And Cheetah3D generated Collada files should work nicely in XCode.

The FBX SDK includes it's own Collada exporter and I want to make that available as a alternative export profile in the future. Maybe that one covers some additional workflows.

But that's quite a complex undertaking which has to wait some more time.

Bye
Martin

 

[Gavin]

Do you have a link to that tool. I'm still not 100% if I understand you right.

Blender has functions for it, the same is the case with Maya / Maya LT where the optimize function will place all uv's for a material into a square canvas. I often see Wings3D mentioned as having it too, but I have never used that application.

I'll have to prepare a file for you so you can see what I mean.

 

[Gavin]

The DAE workflow is very difficult since it requires tons of testing to find a configuration which works well for most apps.

Yes it is, but most applications understand the unit meter better than centimeter. So reverting back to that would help.

 

[Gavin]

The first things that pops into my eyes is that you use almost no hotkeys. That makes your workflow extremely slow of course. Especially the most commonly used polygon tools should be assigned to hotkeys. Once you use hotkeys for these tools the workflow will be much faster. No matter if you use v6 or v7.

Having one level of submenus is totally fine if you ask me. Just look at Mail, XCode, Text Edit, etc. which all have one level of submenus. So that should be no violation of the Human Interface Guidelines.

I'm also pretty sure that one commonly used context menu for all modes is way easier to mesmerise than multiple different.

It's always possible to discuss UI decisions extensively since UIs are always very subjective and I'm 100% that it is not possible to make everybody happy but so far the new menu structure was received positively.

I have doubts if it is worth delaying new 3D features because of a redesign of the context menus.

Please give hotkeys a chance.

Bye
Martin

P.S. Screenshots of Mail and XCode attached.

Personally I use the amount of hotkeys I need to get by.

For Mac users in general, the majority of shipping configs do not have extended keyboards and F-keys are in general awkward to use because it often requires pressing additional modifier keys (Fn). For a complex application finding a good combination of (unused) keys that don't clash with other system or by convention reserved keys is often nontrivial. Even more so for an inexperienced user. F-keys are not easily remembered also, particularly since they don't transfer to other apps.

The entire point about pop-up menus is they are supposed to be contextual, which the C3D menu is not. The examples from Xcode and Mail are exactly that – even if they have system services in the lower part of the menu. Also these are contextual.

I would gradually change the C3D popup to be true contextual, fully acknowledging it is not trivial, so it can happen over many versions.

 

[Gavin]

Do you have a link to that tool. I'm still not 100% if I understand you right.

Enclosed is a stupidly simple example of what I mean.

The first mesh is just two primitives combined into one shell with the default UV map completely untouched. As you see there is overlap between the polygons and it is rather unordered.

The second mesh has a baker applied to it and applied to UV1. The result is nice unwrapping and the polygons nicely placed on the texture canvas.

In the third mesh I have merged another default cube and again applied a baker to it and UV1. Again the polygons are nicely stacked on the canvas.

So C3D already have the functionality to tidy up the UVs and fit them nicely to the canvas, you just have to use the baker workaround to tap into it.

Hope this explains what I am after.

 

[Martin]

In the image below you can see a mesh that has 3 materials mapped to different sections of the mesh, but projected into the same UV surface. It makes for a horribly cluttered UV map to work with.

If you zoomed in to the UV map or the model you might see that parts of the model is very dense (and this is a low poly model so it can be MUCH worse.)
Sometimes you need to adjust the geometry or delete geometry from such an object but making selections on the model itself can be particularly tough of the geometry is inside or small. In this case it can often be much faster to make the selection in the UV map as you see on the screenshot.

In 6.x geometry selected in the UV map could always be deleted from the model just by hitting the macOS Backspace key regardless if you had the Select tool or the Move, Scale, Rotate tool active , but in 7.3 it is never consistent if you can delete the geometry or not. Sometimes it just beeps regardless of what you do and the UV window must be closed and you can try again. Other times it will work if the Select tool is active, other times not.

Perhaps you tried protecting the user from inadvertently deleting geometry when in the UV editor, but the ability to do so was of great help when working on complex models or for fast cleaning up an existing model where you only wanted to reuse parts of it as the base for a new one.

The delete command in the UV editor has been completely disabled since it caused way too many problems. Especially the result of the point and edge delete confused users.

Please use the 3D view for deleting polygons. Cheetah3D has a "Group select" tool which allows to select UV islands in the 3D view.

 

[Martin]

Enclosed is a stupidly simple example of what I mean.

The first mesh is just two primitives combined into one shell with the default UV map completely untouched. As you see there is overlap between the polygons and it is rather unordered.

The second mesh has a baker applied to it and applied to UV1. The result is nice unwrapping and the polygons nicely placed on the texture canvas.

In the third mesh I have merged another default cube and again applied a baker to it and UV1. Again the polygons are nicely stacked on the canvas.

So C3D already have the functionality to tidy up the UVs and fit them nicely to the canvas, you just have to use the baker workaround to tap into it.

Hope this explains what I am after.

OK, I understand. I looked into the Bake tag again and the functionality is indeed different implemented. In the bake tag I don't perform the LSCM algorithm but just an cubic UV projections. With all its weaknesses and advantages.

I've put such a tool onto my todo list.

 

[Martin]

Let me answer this one first because it is the easiest: In previous versions using the scroll function of the Magic Mouse would zoom the view. In version 7 you have to press a modifier key (alt) to zoom the view.

This is annoying because the standard behavior as implemented in most macOS applications is to zoom the view (2D or 3D) when you are outside the scrollbar regions of a window. By assigning a modifier key to this you both have to unlearn acquired behavior from other applications, but in addition behavior from past versions of Cheetah.

From a general usability perspective, implementing standard behavior in an application lowers the barrier for entry, and will usually increase the retainment and continued use of the application when a new user downloads a trial version. Meaning it will increase the likelihood of the trial being converted to a purchased license.

In addition, the scroll function of the Magic Mouse will in version 7 in many cases change the selection range of a tool, something that is highly undesirable if you work in detailed UV maps or doing careful selections say when you re-topo an existing model. It would therefore be better if you implemented this with either a modifier key or had a preference lock to disable the behavior leaving it to the user to set the range explicitly.

I am a bit surprised you actually don't have a Magic Mouse for testing as this is the mouse shipped with all Apple systems without trackpad, including the iMac Pro.

It is better for new users that the application works as good as possible with the standard equipment they are likely to have, and not (implicitly) ask them to buy a 3 button mouse for everything to work satisfactory.

When Vista was released by Microsoft, Apple mocked them in one of their commercials with the phrase "Ask not what Vista can do for you. – Ask what you can buy for Vista". There is good wisdom in this; don't ask the user to buy additional components to use your product. At least not unless you are in highly specialized market where such purchases is expected. I believe Cheetah3D has qualities and capabilities that could bring it to a large swat of Mac users.

This has been already discussed in another forum thread. Although ALT+Scroll wheel is also Apples preferred method for zooming (open a 3D model in Preview app). And although is is very consisted (all camera navigation modes use ALT + X) it is still controversial.

So the next time I touch mouse controls I will make them 100% configureable.

I have a MacPro which doesn't come with a MagicMouse 2. But I had a MagicMouse 1 which was super unergonomic (like pretty much every Apple mouse of the last 20 years) so I usually use an old school Microsoft 3 button mouse with scroll wheel and wire.

But I will use the Magic Mouse 2 for testing purposed once I received mine.

 

[Martin]

Yes it is, but most applications understand the unit meter better than centimeter. So reverting back to that would help.

If the other app ignores the unit I can just recommend to file a bug report to them.

 

[Hasdrubal]

... unergonomic ...
But I will use the Magic Mouse 2 for testing purposed once I received mine.

I don't have trouble with using the mouse in Cheetah. But it's nice to read that you will use the Magic Mouse 2 for testing. It's not just that it's commonly used, but for left handed people like me one of the few usable mice.

I know, it's far away from the themes of this thread, but I like about Cheetah that no middle mouse button is needed or at least preferable. Getting a mouse, that fits in the hand like it should isn't that easy for lefties. There are no ergonomic mice for us I know of (Logitech had once one). And those for both hands are mostly inprecise, too bulky, too cheap. Last time I had to buy a mouse, I tested literally everything I could lay may hands on till I found a Steelseries Gamer Mouse that fits well into my hand.

So, when I made the switch to Mac I expected to have to do that again, especially when I found out that there are no actual drivers for the old mouse (as it has it's own os built in it shouldn't need one. There is just one functionality missing there: The switch between left and right mouse clicks). But after a short while the Magic Mouse 2 grew on me. It's not too big, not too small. The only thing that's unnerving is the scroll function sometimes and I wish they would incorporate some simulation for a middle mouse button (I know, there exists an app, but there are at least longterm reasons not to use that). But overall, I like it very much.

One of the problems is, that most lefties use the mouse with the right hand. I did that, too, for a long time, but for precise work like editing images, 3d modeling, paint etc. that doesn't work. But the market is very small, and right handed people prefer ergonomic mice. They sell better than something created for the 'wrong hand'.

 

[Gavin]

The delete command in the UV editor has been completely disabled since it caused way too many problems. Especially the result of the point and edge delete confused users.

Please use the 3D view for deleting polygons. Cheetah3D has a "Group select" tool which allows to select UV islands in the 3D view.

The problem with group select for complex models that have double or internal geometry (such as the teeth, tongue and eyes of a character's head) is that it selects too much and you have to deselect via a lot of zooming and clicking.

A workaround for this is to do a rough group selection on the model, and then use the uv map where the geometry usually is clearly separated to do the deselection before deletion of the geometry on the model.

I agree with you that point and edge deletion from a selection on the UV map is probably more confusing and destructive than useful, but it would be a great timesaver if polygon deletion could be enabled via a preference toggle "Allow deletion from uv map selection".

 

[Gavin]

OK, I understand. I looked into the Bake tag again and the functionality is indeed different implemented. In the bake tag I don't perform the LSCM algorithm but just an cubic UV projections. With all its weaknesses and advantages.

I've put such a tool onto my todo list.

Ok - to make it clear the function requested is to place already unwrapped geometry in a most efficient manner on the uv canvas, and NOT apply an LCSM algorithm to it. (in the case of the test file it would produce a horrible result).

 

[Gavin]

If the other app ignores the unit I can just recommend to file a bug report to them.

They are not going to "fix" it unless there is a change in the Maya -> Autodesk converter chain, and then it will still have to be able to accept potentially hundreds of thousands of existing DAE files for re-upload, many of which have been sold commercially.