Thank you Martin!
Merry Christmas and a Happy New Year to you, your family and everyone here in the forum.
Merry Christmas and a Happy New Year to you, your family and everyone here in the forum.
Cheetah3D 8.0 Public Beta (with native Apple Silicon and Metal support)
- Thread starter Martin
- Start date
Just when I thought Apple's throttling of the CPU was going to be the new norm! It's Christmas morning here, so thank you Martin for the timely fix/update. I'm looking forward to the return of full speed rendering! Merry Christmas everyone.
Helmut
0
Merry X-Mas to all Cheetah 3D cubs! Sadly, wishes for a Happy New Year seem increasingly cynical, naive and simple-minded. Whoever invented the taxon "homo sapiens" was grossly mistaken and should have stayed in Uppsala. Oops, that is where he was interred, so I assume he wont be moving posthumously.
ZooHead
0
Merry Christmas and a happy new year to everyone.
I spent my pre-Christmas in the dark after the worst wind storm in my life.
Trapped in my house by trees for five or six days,
I'm just now getting phone/internet service back.
The trees are now being chainsawed away so I can get food and water delivered.
At least no trees hit the house, but one only missed by three feet.
I got the power back the day before Christmas, but I'm still trapped until the tree crew finishes today.
I spent my pre-Christmas in the dark after the worst wind storm in my life.
Trapped in my house by trees for five or six days,
I'm just now getting phone/internet service back.
The trees are now being chainsawed away so I can get food and water delivered.
At least no trees hit the house, but one only missed by three feet.
I got the power back the day before Christmas, but I'm still trapped until the tree crew finishes today.
Hello, I’ve started a new thread about b6 and b7 saturating only 50% of the available processor resources when set to 0.
Cheers,
gsb
Cheers,
gsb
Martin
0
Hi,
I've released Cheetah3D 8.0 Beta 8 today. It fixes a critical performance bug on Intel Mac which slowed down the renderer considerably. It also adds some memory usage optimisations for Metal. This might be the last beta version of Cheetah3D 8.0. I want to bring the v8 development to and end and work on some new stuff after those endless years of switching.
You can find beta 8 at:
https://www.cheetah3d.com/download/Beta/Cheetah3D8.0b8.dmg
Change log:
-enabled VSync in 3D view
-fixed bug in "Max. texture resolution" setting
-fixed rendering performance bug on Intel Macs
-fixed missing textures bug in SCN importer
-fixed undo bug when rendering scenes
-fixed some problems with velvet shader
Kind regards
Martin
I've released Cheetah3D 8.0 Beta 8 today. It fixes a critical performance bug on Intel Mac which slowed down the renderer considerably. It also adds some memory usage optimisations for Metal. This might be the last beta version of Cheetah3D 8.0. I want to bring the v8 development to and end and work on some new stuff after those endless years of switching.
You can find beta 8 at:
https://www.cheetah3d.com/download/Beta/Cheetah3D8.0b8.dmg
Change log:
-enabled VSync in 3D view
-fixed bug in "Max. texture resolution" setting
-fixed rendering performance bug on Intel Macs
-fixed missing textures bug in SCN importer
-fixed undo bug when rendering scenes
-fixed some problems with velvet shader
Kind regards
Martin
Thanks for the update.
Still alpha trancparency does not render correctly with default material, neither Cheetah not Falcon.
Both work with PBR material.
Also I got crazy results in the Metal viewport until enabling HDRI background which works okay.
Tested on MacBook M3 with Sonoma.
Edit: My fault, reason was IOR = 1,5 insterad of 1, works now!
Both work with PBR material.
Also I got crazy results in the Metal viewport until enabling HDRI background which works okay.
Tested on MacBook M3 with Sonoma.
Edit: My fault, reason was IOR = 1,5 insterad of 1, works now!
Last edited:
Another problem:
When I export the rendered animation from the attached project with one of the ProRes codecs from the render manager suddenly the white background turns green.
It does not happen with h.264, h.265 or GIF export.
Also the PNG files in the render history look okay and Quicktime player produces a correct ProRes from the imported image sequence.
Beta 8 with Sonoma on MacBook M3.
When I export the rendered animation from the attached project with one of the ProRes codecs from the render manager suddenly the white background turns green.
It does not happen with h.264, h.265 or GIF export.
Also the PNG files in the render history look okay and Quicktime player produces a correct ProRes from the imported image sequence.
Beta 8 with Sonoma on MacBook M3.
Still works with M1/BigSur:
I don't want to get ahead of myself, but I suspect Sonoma is the cause.
I don't want to get ahead of myself, but I suspect Sonoma is the cause.
Just retested and you're right, on MacBook Air M1 Monterrey the green stuff doesn't happen, neither with v8b7 nor v8b8.
On Sonoma the bug also happens with v8b7.
Last edited:
Hello,
C3D 8.0b8
Intel 2019 MBP running Sonoma 14.2.1, your file, rendered, saves to ProRes 4444 and plays as intended with white background.
Intel 2019 MacPro running Ventura 13.6.3, your file, rendered, saves to ProRes 4444 and plays as intended with white background.
No green artifact.
Cheers,
gsb
Hi Martin
A problem that I had on my old 2012 iMac (Catalina) with C3D V7, has resurfaced on my M2 Mac Studio C3D V8 over the last week or two. Nine times out of ten, when I go to edit a field, the field loses focus. Sometimes this happens as soon as I click into the field or select the number that I want to overtype, sometimes it loses focus a second or two later. It looks like it might be related to moving the mouse after selecting or clicking into the field.
I have recorded a short video to explain what is happening.
capture.dropbox.com
A problem that I had on my old 2012 iMac (Catalina) with C3D V7, has resurfaced on my M2 Mac Studio C3D V8 over the last week or two. Nine times out of ten, when I go to edit a field, the field loses focus. Sometimes this happens as soon as I click into the field or select the number that I want to overtype, sometimes it loses focus a second or two later. It looks like it might be related to moving the mouse after selecting or clicking into the field.
I have recorded a short video to explain what is happening.
Dropbox Capture
Create and share screenshots, screen recordings, and video messages with the Dropbox Capture. Download and try Capture for free.
I remember Martin implemented a mouse drag from the panel to be interpreted as a return/enter and that´s still working that way here. I´m not able to recreate what you experiencing. How do you highlight the value in the entry fields? Does work "tab"-key to zap through all the fields incl. highlighting?
Hi Frank
Thanks for looking into this.
I use my mouse and click into the field, then delete and retype, or I drag over the value, then overtype it. Sometimes I double-click the value to select it.
I tend not to tab around the fields. That's so last century
Everything worked fine for a few months on the new Mac Studio. On the 2012 iMac, it all worked fine for many many years. On the Mac Studio, it's all new equipment, mouse, keyboard, computer, etc, so I wasn't expecting this problem to reappear.
Just gave it another go.
If I Tab, the value in the field I tab to is selected for overtyping. But that would require me to click into an adjacent field and tab to the field to select the value that I want to modify. I'm right-handed, but operate the mouse with my left hand, so I have to take my hand off the mouse to tab (I use a left-handed mouse). If I return my hand to the mouse and move it, the field again loses focus.
Whether I click into a field, double-click the value, tab into a field or use the mouse to drag over a field’s value, it's the same thing. It's the ongoing movement of the mouse, whether intentional or not, that causes the field to lose focus.
The only other thing I can think of is perhaps it was a bug in an old file I opened. It doesn't happen in other apps.
Thanks for looking into this.
I use my mouse and click into the field, then delete and retype, or I drag over the value, then overtype it. Sometimes I double-click the value to select it.
I tend not to tab around the fields. That's so last century
Everything worked fine for a few months on the new Mac Studio. On the 2012 iMac, it all worked fine for many many years. On the Mac Studio, it's all new equipment, mouse, keyboard, computer, etc, so I wasn't expecting this problem to reappear.
Just gave it another go.
If I Tab, the value in the field I tab to is selected for overtyping. But that would require me to click into an adjacent field and tab to the field to select the value that I want to modify. I'm right-handed, but operate the mouse with my left hand, so I have to take my hand off the mouse to tab (I use a left-handed mouse). If I return my hand to the mouse and move it, the field again loses focus.
Whether I click into a field, double-click the value, tab into a field or use the mouse to drag over a field’s value, it's the same thing. It's the ongoing movement of the mouse, whether intentional or not, that causes the field to lose focus.
The only other thing I can think of is perhaps it was a bug in an old file I opened. It doesn't happen in other apps.
Last edited:
I'm still not able to replicate. Is there perhaps a multiple monitor set up involved? Just trying to collect infos. 
re: editing fields…
Hello,
Chris, I have, at times, experienced similar field editing troubles.
Frank, I'm glad you chimed in on this. For some time I have been looking for an earlier reply, from you, on some thread, referencing the effort Martin put in to change the behavior of modifying fields, and that he was unlikely to change it after getting things to behave the way he wanted. I wanted to find that thread to get context for my experience of editing the value of fields that frustrates me. Since I did not find it, I had no relevant C3D-intent context to frame a comment.
I use a Wacom tablet and pen to "mouse". While I can recreate the troubles I have with editing the value of a field with an actual mouse (or touch pad on my MBP), using the tablet it is hard to NOT have the issues. Now that I have Frank's comment as some context, it would seem this is because C3D interprets some particular movement of the cursor, after a field-content selection has been made, to be (if I understand Frank correctly) the indication that I have completed the editing process.
I sometimes use tab and shift tab to progress/regress through fields, though it is not the way I do it if I need to change only a single digit's value rather than all of the digits of the value. The up/down field arrows are typically not the level of granularity I want when editing a single digit of a numerical field.
Tabbing to a field then using the cursor key to go to the end of the value to enter a mathematical expression (e.g. *10 or -.15) works, but as Chris referenced, tabbing isn't always the most direct way to do something.
As an added complication for me, over the years and for whatever reason, I have developed the practice of selecting editable text/numbers from the right back to the left rather than from the left to the right.
Selecting any editable text or number in C3D (e.g. field contents or material name), from right to left will result in the un-selection, of that selection, almost instantly regardless of the "mouse" device.
Frank, I had NOT thought to try, so I have yet to explore whether or not multiple monitors affects the behavior. But if multiple monitors comes into play, why only with C3D? In my experience, this direction-of-selection behavior seems exclusive to C3D, as I have NOT experienced it using any other application, certainly not in the Finder.
Selecting the same text from left to right typically behaves "better" in preserving the selection, but spurious movement after selection results in deselection.
Back to the beginning of this message and my reference to an ancient comment by Frank on text selection in C3D… I have not mentioned this directly* before now and have accepted that I will, at times, get frustrated editing such things. To cut down on my frustration, if I have a lot of field editing to do, I turn on my Magic Mouse and edit the text/numbers using it, but that opens a whole other batch of how-did-I-change that issues.
* I did ask Chris, perhaps in this thread, how he liked his new M Mac running 8.0b and how editing fields was going, as he had referenced that one thing he was looking forward to was better field editing. He replied that things were working fine.
So, I just wanted to confirm that Chris is not the only one who has troubles when it comes to editing fields. I do wonder why it seemed to be working for him the way he expected, but then stopped.
Cheers,
gsb
Hello,
Chris, I have, at times, experienced similar field editing troubles.
Frank, I'm glad you chimed in on this. For some time I have been looking for an earlier reply, from you, on some thread, referencing the effort Martin put in to change the behavior of modifying fields, and that he was unlikely to change it after getting things to behave the way he wanted. I wanted to find that thread to get context for my experience of editing the value of fields that frustrates me. Since I did not find it, I had no relevant C3D-intent context to frame a comment.
I use a Wacom tablet and pen to "mouse". While I can recreate the troubles I have with editing the value of a field with an actual mouse (or touch pad on my MBP), using the tablet it is hard to NOT have the issues. Now that I have Frank's comment as some context, it would seem this is because C3D interprets some particular movement of the cursor, after a field-content selection has been made, to be (if I understand Frank correctly) the indication that I have completed the editing process.
I sometimes use tab and shift tab to progress/regress through fields, though it is not the way I do it if I need to change only a single digit's value rather than all of the digits of the value. The up/down field arrows are typically not the level of granularity I want when editing a single digit of a numerical field.
Tabbing to a field then using the cursor key to go to the end of the value to enter a mathematical expression (e.g. *10 or -.15) works, but as Chris referenced, tabbing isn't always the most direct way to do something.
As an added complication for me, over the years and for whatever reason, I have developed the practice of selecting editable text/numbers from the right back to the left rather than from the left to the right.
Selecting any editable text or number in C3D (e.g. field contents or material name), from right to left will result in the un-selection, of that selection, almost instantly regardless of the "mouse" device.
Frank, I had NOT thought to try, so I have yet to explore whether or not multiple monitors affects the behavior. But if multiple monitors comes into play, why only with C3D? In my experience, this direction-of-selection behavior seems exclusive to C3D, as I have NOT experienced it using any other application, certainly not in the Finder.
Selecting the same text from left to right typically behaves "better" in preserving the selection, but spurious movement after selection results in deselection.
Back to the beginning of this message and my reference to an ancient comment by Frank on text selection in C3D… I have not mentioned this directly* before now and have accepted that I will, at times, get frustrated editing such things. To cut down on my frustration, if I have a lot of field editing to do, I turn on my Magic Mouse and edit the text/numbers using it, but that opens a whole other batch of how-did-I-change that issues.
* I did ask Chris, perhaps in this thread, how he liked his new M Mac running 8.0b and how editing fields was going, as he had referenced that one thing he was looking forward to was better field editing. He replied that things were working fine.
So, I just wanted to confirm that Chris is not the only one who has troubles when it comes to editing fields. I do wonder why it seemed to be working for him the way he expected, but then stopped.
Cheers,
gsb
Last edited:
HI FrankI'm still not able to replicate. Is there perhaps a multiple monitor set up involved? Just trying to collect infos.
My set up is a:
- Mac Studio with M2 Max silicon
- Apple extended keyboard and Apple Trackpad
- Logi M650L Left Mouse
- Scarlet 2i2 Audio Interface with monitor speakers, headphones and mic
- OWC Ministack STX Solid State and Hard Disk Drive
- Dell Ultrasharp 32" Monitor
- Inspired tablet and pen
- Logi Brio 500 Webcam
The old system is a 2012 iMac running Catalina with 24Gb of memory and a 3TB Fusion Drive, with a Steel Series mouse, Apple keyboard and Apple trackpad, plus a couple of external hard drives which are no longer attached.
Given I have the same problem on both Macs, I don't think it's related to the hardware.
Thanks gsb for chiming in. It sounds like you have the same issue. I think that dragging over the text from left to right works better than dragging from right to left, and this may be because I'm less likely to nudge the mouse and lose the selection. It is annoying when every field behaves this way and it does slow down productivity.
I can confirm there was this selection issue in the past, but thankfully currently with both my Apple silicon Macs (M1/10.12.7 & M3/10.14.2) and v8beta it is gone and selecting parameters just works.
Somehow I cannot recall the hardware/software constellation when the problem persisted, sorry.
Somehow I cannot recall the hardware/software constellation when the problem persisted, sorry.