Modo 10 live (plus 30-day trial)
polycounter lvl 10
TF learned from their 901 mistakes (buggy) so they're including the trial on day one (unprecedented!). Test it boys...and girls.
Maybe I'll upgrade when .1 comes.
https://modo.thefoundry.co.uk/
Fresh batch of Modo 10 feature videos:
www.youtube.com/channel/UC3gcz4qAcvMtrVCiRZvEnzg/videos?view=0&shelf_id=0&sort=dd
Maybe I'll upgrade when .1 comes.
https://modo.thefoundry.co.uk/
Fresh batch of Modo 10 feature videos:
www.youtube.com/channel/UC3gcz4qAcvMtrVCiRZvEnzg/videos?view=0&shelf_id=0&sort=dd
Replies
Are they going to upgrade indie version to 10 too? With that game-artist oriented tools I think it would be great.
So many things are weirdly done in modo.. And this is a software which is supposed to be a modellers dream.
(side note, man these forums feel a lot more empty/inactive since the style changed.)
I think its the visual change in the forums, its just so much harder to read and interact. Feels more tablet friendly than PC friendly.
Some interesting info on http://www.alexa.com/siteinfo/polycount.com
I miss the old PC with all its activity. =(
However, it looks like an enable bug has slipped in, allowing the command to be enabled when it shouldn't be. I'll fix that for the next version.
If you use it with a single foreground and a single background mesh, it should work fine.
Despite Modo definitely getting better each year, I feel sad all this gamedev love happens few years after I was really interested in Modo (but was thrown back by lots of small annoying things, weird workflows and overall UX).
Nowadays I just can't feel too much of a benefit coming to Modo from Autodesk suites (we have both of them at work) for my type of work.
Still I hope the software will continue to improve
And re: cheaper (but gimped) indie version, no word far as I know when the next version release is going to happen.
The viewport truly looks fantastic - by the look of it it seems like the new landmark for other apps to aim for. Now I've always had reservations about Modo as a modeling tool because each version I tried in the past had a certain sluggish feel to the UI and toolset and this is probably still the case, but with this new viewport this could become a great companion app. Glad to see that they are finally offering a traditional trial version too. Exciting !
Recently I tested viewport performance in windows and linux with a basic scene (default viewport). The results I got were somewhat surprising, you can see them here.
As soon as I can figure out how to disable vsync with AMDGPU I'll get some proper numbers. I'd be interested in seeing results from other hardware setups too.
However, it being precise also depends a lot on whether or not the placement of the center of rotation/zoom behaves predictably, and this has been an issue with the Max and Maya viewports since ... forever, pretty much.
Really curious to give this demo a spin. I'll definitely report here in a few days after trying it out to elaborate on the topic of feel/delay.
Funny that you mention that; the changed camera limits in 901 seemed a negative to me, it was much harder to zoom in on certain pieces of small scale, as if the camera limits were much tighter. So you'd try and pan in to a small interior/concave area, only to have the camera locked to a snail's pace. WASD navigation possibly makes that a non-issue now though.
I just did another test on linux (still haven't found out how to disable vsync) but with one 2 million tri sphere instanced 7 times (for 18mil total tris) I still had 60fps with wireframe disabled. Which blows CCC's win/linux performance out of the water. So now I'm wondering what performance nvidia users get as that would help determine if CCC just sucks in all instances, or if AMDGPU's openGL performance is just amazing.
To disable vsync you need to edit ~/.drirc: https://wiki.archlinux.org/index.php/ATI#Turn_vsync_off If you're using DRI3 with AMDGPU (which I believe is not the default right now) you would probably need to change the Driver tag to dri3.
I don't know whether this works on AMDGPU and I haven't tested it on my machine because I have no desire to benchmark, but it should work.
Modo does seem to have a little bit higher latency to me, but it's well within reasonable bounds.
Does anyone know if 10 exposes functions for fully customized viewport shaders, Guilty Gear Xrd style? Bonus points if you can import Unity shader files and use them in Modo, that would be super fresh.
@JedTheKrampus Aha, thanks, that got it with the dri2 tag. I'd assumed the ATI config stuff was irrelevant for the amdgpu driver. Updated the sheet with new numbers. Anyone with a nvidia card willing to do some tests?
Also for creating a cage, under lists (tab generally on the lower right region of layout)... create a morph map (call it something like "Cage")... then under deform (tools on the left) use the push function. This balloons the mesh a bit to be used as a cage. Then click on your morph map layer again to turn it off. When you go to bake, you will see your "cage" morph map listed under the cage option within baking tools.
I know I am probably missing on a ton of great features, but first impressions (and the fluidity of very basic operations !) matter a lot. In this state I personally don't find it to be usable.
Of course there is always the suggestion of getting some top of line hardware to compensate, but I don't think this is a solution when other programs run around Modo in circles, on the same machine ... There's definitely a problem here.
First thing to do is in the command box (lower right), type in "glmeter". This will give performance info directly from Modo.
After that, go into settings >openGL> and you have some options under the performance tab. Some get a huge boost by turning off VBO.... huge. When I did it, my FPS spiked by at least 500... though I generally keep it on since its currently playing nicer with the advanced viewport mode.
Your menu delay isnt that bad on my end, but granted its not as zippy as Blender (which I believe you moved over to correct?). At that point it comes down to deciding on whether or not the menu feel is important enough to be worth or not worth the other benefits in Modo.
I am running an Nvidia card here, and the VBO toggle didn't seem to affect performance (framerate still varies wildly, and menus are still slow).
Now that's not a huge deal for me since I wasn't planning to explore Modo further than for its rendering and viewport anyways - but still that's some interesting data for the Foundry guys I suppose, as I am probably not the only one getting low performance out of the app. I think I have tried every big Modo release over the last few years on a variety of systems and as far as I can remember it's always been like this, which is certainly worrying.
Did you restart Modo after turning VBO off? Its a tad annoying but its a requirement to get that boost after turning it off for the first time.
The viewport is definitely what got me to upgrade, not so much the renderer. There are lots of good ones out there so the need wasnt all that important. The next (free for 10 users) feature update 10.1v1 involves something both Blender, 3DS Max and XSI have. I'm sure some of you can connect the dots and get an idea what I am referring to. Its also accidentally leaked here (by their own, so its ok): http://content.luxology.com/modo/modcast/2016-04-11MODCAST10.m4a
That might sound appealing to you as well, but hard to say.
Well, it certainly was an issue for me as shown in this video, since basic operations on a default sphere were not giving satisfactory performance. Granted not everyone has the same needs, but as far as I am concerned I rate it as not acceptable.
If that occurs on your PC, it might be caused by an another app running in the background (ex: Raptr, etc.) or someone running the illegal version of Modo 10.
Or ... it might be caused by the software being poorly optimized. I am Not trying to be dismissive just for the sake of it here, but that's probably the most logical explanation ...
1) 0:00-0:10 - viewport performance is fine for me (obviously you have v-sync on)
2) 0:10-0:30 - extrude tool - OK, this is weird, but I think I can explain the second half. Why using the extrude tool's handles would have poor fps is a mystery, because doing the exact same thing via the move tool has no fps impact. I don't think I've ever really noticed this because normally if I extrude something I'll bevel (or extrude) and drop the tool and switch to the move tool, as I prefer its handle. As for the 1fps when using the spinner, I'm confident this is because it only updates the viewport once the spinner stops spinning. It's not that performance is so horrid it's capped at 1fps; it's just that it's not attempting to update. Type in any numeric value and you'll see the transform applied instantly. Jitter the spinner and you'll notice it won't feel laggy at all. For a similar behaviour, try zooming in/out using the mouse wheel, first slowly, then quickly while observing FPS. It's like the FPS is an averaged value over a limited time, so slow scrolls = low fps reading, while quick scrolls = more updates per second = higher fps reading. But, the true fps is the same.
3) 0:30-0:46 - title bar - I get this too, but until you'd pointed it out I'd not noticed. It seems once you go over a certain speed it doesn't even attempt to drop down the menu - if you move the mouse across the title smoothly every dropdown will snap open quickly, any faster and it skips. Odd, but not something I've ever found hindering. IF you get lag within the dropdown menu, then we have a problem (I do not). But again, I've no real experience with other packages so I can't make any bold claims; perhaps I just don't know any better.
Also all this talk of viewport FPS without mentioning conditions / tri count is pointless. Replicate these tests and list your gpu/cpu please. I'm curious what performance nvidia cards get. And more generally, let's be wary of jumping to conclusions without investigating what is actually occuring.
@JedTheKrampus did you ever get the toolkit compiled? If so share the wealth
So, if I am not mistaken you are more or less getting the same results as I do, which hints at the fact that these performance drops might be quite common. Now of course the experience from one machine to another may vary (for instance @Tidal Blast doesn't seem to run into any of these problems, and that's great !) ; but if these delays are actually"built-in" (like the menu lag, and the spinner response down to 2fps) then these design choices are not doing the software any favors. I personally don't see much point in testing performance at higher workloads, since the performance already feels sub-par to me when performing very simple tasks. Of course such tests could be valuable for the devs, but I am not looking at Modo from the perspective of a beta tester but rather from the perspective of a potential customer curious about the software and willing to be impressed.
Anyway, I don't really have a proverbial dog in this fight so at the end of the day this doesn't affect me that much - I probably won't dive into the software any further in this state. These remarks and the video are mostly a way to shed some light on the earlier comment by me and @Thomasp about previous releases feeling sluggish.
I totally understand that not everybody has the same setup, and that different users have different expectations. But as far as I am concerned the first impressions were poor.
It's possible that Modo doesn't work very well with your GPU. It's possible that Modo doesn't work very well with your current GPU drivers.
Yes, it's very possible ! And again, this is a matter of expectations. I simply expect something more robust out of high-end software.
The spinner low fps is not a bug, it's just a misinterpretation. The software is reporting a low fps value because it is only updating the viewport at odd intervals (when the spinner stops). If you drag the spinner for one second the viewport updates once after that one second, you get 1 frame per second. But there's no "lag" or "delay" involved, it's just that the viewport didn't need to update because nothing changed until the spinner stopped. The viewport could've been refreshing at 120fps during that time and it would've made no difference because the spinner is not interactive in that way. It's in no way indicative of a performance problem, nor is it something that will interrupt your work. It's just how the spinner was designed. If simple translations were impossible to do without crippling your viewport performance, people would not use modo. So again let's not jump to hasty conclusions when we see a 2fps reading.
The reason I'd like to see other results from the sphere test is to find if there's a wide range between viewport performance for different hardware/software configs, and that seems like a fairly repeatable and simple way to get data. If anyone has any other odd cases of performance issues that can be measured/tested I'd be interested in trying them (for my own curiosity). Anyway, thanks for that video, it was interesting to see. If you're done testing modo that's fine, but I'd encourage you to give it another chance, it's a great app and I really enjoy using it.
Again, it's a matter of expectations. I personally do expect these things to be extremely snappy and, well, flawless. I do understand that these sort of things do affect users differently than others of course.
yes the interface stuff you show in your video is what i meant. as i recall switching between different tabs had me watch the program redraw the individual interface elements, resizing the UI was a slow affair and even the little confirmation dialogs popped up with a visible delay. not a deal breaker to work with but not reassuring when it happens in an almost empty scene either.
couple that with the fame it always had in forums for being picky regarding choice of graphics cards/driver and it never made it on my radar properly.
cheers
You're right in that there's no actual slowdown, but it can appear that way as the viewport doesn't refresh asap. The "lazy" update of the viewport is what makes it show very low FPS (it IS low FPS, but it's not because it's incapable of being fluid, as it were).
It's a known issue, we're working on speeding it up.
That said ... performance drops are very noticeable to me and definitely a very important factor when picking a tool that I would potentially spend hours on. Again, a matter of expectations - and "negative attention" like my documented video report is totally fair, and if anything very much needed in order for such issues to be eventually addressed. I mean, wouldn't it be great if the sliders refreshed faster ?
Now it's totally cool if these problems do not affect some users ! But as said, first impressions matter a lot, and instantly noticeable UI/UX oddities are always a red flag to me ... especially if I stumble across at least 3 of them within 5 minutes of trying out the software.
@Farfarer : interesting !
Oh I dont mean the video is merely negative attention, but rather the approach of "hey look it still had this menu delay when I spaz my mouse around". What I am trying to get at is that most artist are not going to be working in that spaztastic manner nor would their ability to work suddenly stop because the menu didnt appear fast enough when running the mouse back and forth. My hope is that such minor nitpicks are not the limit to which you test software or delve into its workflow.
Some people wont go past that superficial level and its just a tad frustrating because its not really noticeable unless you have some number in front of you. I dont think these applications should be a race for reaction speed as opposed to workflow speed. Maybe its just that I cant see it the same way. I worked with both Maya and Blender before going with Modo. Sure there is a noticeable difference in feel, the smooth vs jumpy, but thats pretty much where it ended.
Now the Foundry has people like Farfarer working for them, Greg Brown, Brandon and others who love game dev just as much as the next guy/gal. They have left their mark, you can see it in version 10. It would be a shame it the "testing" or evaluation never went past the spaztastic menu test. I just hope you can continue to give it a fair shake, thats all.
All that said, I thank you for going through the motions and getting involved. I dont want this to sound negative or judgemental, rather just a shared passion for these kind of apps.
fistbump
And as matter of fact, in my experience devs tend to appreciate this kind of stress testing because it allows them to identify underlying problems that might have gone unnoticed.
Of course a piece of software cannot be reduced to its issues. But I am not a beta tester, but rather a curious customer - when I notice that manipulating the result of a simple extrude operation causes the framerate to drop by half, I do take it as an indication of what to expect further down the line. It is only natural, and something that the devs should definitely keep in mind. And as Farfarer showed they certainly do, so that's good.