Mari 1.1 For Windows and Linux Now Available

[DuttyFoot]

i am trying it out again after 3 hang ups and force restarts. i was finally able to load the goggles model and i tried to rotate around the object using the maya way. sorry, but i am so used to the maya way of moving that i tried the alt mouse routine. doing that put a blotch of white on the goggles. now its frozen again, LOL

[HughBowen]

you seems just the minimum req. arent gonna cut it

[forelle]

i am trying it out again after 3 hang ups and force restarts. i was finally able to load the goggles model and i tried to rotate around the object using the maya way. sorry, but i am so used to the maya way of moving that i tried the alt mouse routine. doing that put a blotch of white on the goggles. now its frozen again, LOL

Hi

Sorry you're having problems. Any chance you could you send us an email at support@thefoundry.co.uk with some more info like your system specs and gpu driver version? Thanks.

Jack

[PaulAdams]

Good lord, this is slow. I guess when they say minimum requirements they literally mean the bare minimum to open the app, as loading even a medium resolution mesh brings it to a crawl on my system.

[forelle]

Good lord, this is slow. I guess when they say minimum requirements they literally mean the bare minimum to open the app, as loading even a medium resolution mesh brings it to a crawl on my system.

Hello,

Could you let me know what GPU you have?

Mari really does need the minimum requirements. If those are met, it will scale upwards almost infinitely in terms of texture data, unfortunately to get that scalability, we needed to make some design decisions regarding GPU memory etc.

The minimum requirements are at least 1Gb of GPU ram and OpenGL 3.0 support.

Thanks

Jack

[PaulAdams]

Hello,

Could you let me know what GPU you have?

Mari really does need the minimum requirements. If those are met, it will scale upwards almost infinitely in terms of texture data, unfortunately to get that scalability, we needed to make some design decisions regarding GPU memory etc.

The minimum requirements are at least 1Gb of GPU ram and OpenGL 3.0 support.

Thanks

Jack

nVidia Geforce GTX 285 here, so I guess that I only just meet the min spec. That said, I only barely got it to load a mesh and painted 1 stroke before it froze (guess it was projecting) for what seemed at least 5minute and then closed.

[forelle]

nVidia Geforce GTX 285 here, so I guess that I only just meet the min spec. That said, I only barely got it to load a mesh and painted 1 stroke before it froze (guess it was projecting) for what seemed at least 5minute and then closed.

Hi

Thanks for the reply. The GTX 285 seems to be similar specs to my Quadro 3800M. Can you let me know which driver version you're using? I can edit and paint on at least 4M polys and 400+ 4k textures on my machine. Any chance you could share the model with my so I could try it out on my machine?

J

[DuttyFoot]

Hi

Sorry you're having problems. Any chance you could you send us an email at support@thefoundry.co.uk (http://forums.cgsociety.org/support@thefoundry.co.uk) with some more info like your system specs and gpu driver version? Thanks.

Jack

to be honest i didn't even look for the minimum specs to run the software. i'm running a quadcore 2.2ghz with 8 gigs of ram and a gtx 260. I guess i will have to move up to a better card like a gtx 460 or 480. in my last email i said the googles froze because i tried to click on the other icons in the ui and nothing happened. well, i let the software sit for a while and then tried again, i started moving the mouse pointer to the far right of the screen and then a brush pointer (similar to what is in photoshop) appeared. I was now able to click on the icons in the ui and paint on the googles but i still dont understand why i had a mouse pointer and a brush pointer on screen at the same time. I just got my wacom 4 so i don't know if i have to change the settings to correct this problem.

[forelle]

to be honest i didn't even look for the minimum specs to run the software. i'm running a quadcore 2.2ghz with 8 gigs of ram and a gtx 260. I guess i will have to move up to a better card like a gtx 460 or 480. in my last email i said the googles froze because i tried to click on the other icons in the ui and nothing happened. well, i let the software sit for a while and then tried again, i started moving the mouse pointer to the far right of the screen and then a brush pointer (similar to what is in photoshop) appeared. I was now able to click on the icons in the ui and paint on the googles but i still dont understand why i had a mouse pointer and a brush pointer on screen at the same time. I just got my wacom 4 so i don't know if i have to change the settings to correct this problem.

We've had some teething troubles with the Wacom on Windows and are keeping a close eye on it. If you manage to recreate the problem could you let us know and we'll get it fixed. We'll keep looking at it from our end.

The best possible thing would be to screen capture a video of it happening, but I understand that this may not be possible.

Thanks for the feedback so far.

Please let me know how you get on otherwise. :)

J

[ViCoX]

Silly me, of course mari needs nvidia card. : /
Well, gotta get one at some point anyway.

[forelle]

Silly me, of course mari needs nvidia card. : /
Well, gotta get one at some point anyway.

Hi,

I've been having a look around and the GTX 450, seems very reasonable (http://www.google.co.uk/products?hl=en&client=firefox-a&hs=aYz&rls=com.ubuntu:en-US:unofficial&q=gtx%20450&um=1&ie=UTF-8&sa=N&tab=wf) and should run Mari wonderfully (caveat, we've only done a full QA cycle on 460's and 480's)

J

[caro]

Am I the only one happy with its performance? Nvidia 280 GTX, i7 8 core, windows 7 64bit. Played 15 minutes yesterday and worked fantastic. However, I loaded only about few k polys mesh. Not sure what was the texture size but it was very sharp, I am assuming 4096x4096.

[AlanW]

I think Mari performs beautifully. I've used it on both a GTX 285 and fermi Quadro 4000 with excellent results.

I've never tried Mari on Windows though, but I would expect it to be similar except for possibly some differences between the Nvidia drivers on different platforms.

[twosheds]

I've been hugely looking forward to this coming to Windows. :)
So I just downloaded the trial and installed it. Not knowing what to do I just loaded an object I was recently painting with Mudbox 2011. It has about 75,000 polygons.
So I was able to tumble around easily enough, but it froze for a few seconds after *every* brush stroke.

It looks great and I am planning on learning as much as I can about it and trying it out fully in the time I have.
But to be honest, Mudbox walks all over this particular object - no lag, no delay, and works flawlessly, but if Mari can't compete with that it won't be worth it.
Naturally I expect there to be issues with a first release, and I really hope I'm just doing something wrong.

Windows 7 x64
GTX 285
8 GB RAM
Intel Q9550 quad core (2.83 ghz)

[forelle]

Hello,

Thanks for the feedback!

Mari uses a different approach to painting than some other packages and will pause for a moment to project each time you *move* the camera. It should not pause after each stroke, if it is pausing, without moving the camera, could you share the model with us for testing?

<technical stuff>
Mari works by painting into a screen aligned buffer which is projected down onto the object in real time for preview and at full resolution when required (i.e. when you move the camera position). Hit M to move the buffer around to see this in action.

Although this will make tumble-stroke-paint-tumble-stroke-paint feel slower than a direct paint approach (a-la Mudbox and zBrush) it has some dramatic advantages to work flow that makes detailed texture painting a *much* quicker process.

The first benefit is that your reference / paint strokes can be warped, edited, and adjusted before projection. A huge amount of photo based painting is making the reference fit the flow of the surface. Without good, fast in-context editing tools you have to continually jump forwards and backwards between your 3D and 2D tools for color correction and image editing. Each stroke may feel quicker, but your work flow is much slower.

The second advantage is making a separation between your paint and the texture you're painting into. Although it is not directly obvious you're painting into a buffer that is much higher resolution than the screen, and can project into textures much larger than can be supported via direct paint. With Mari I can paint with an effective brush diameter of 8k across tens of 32k textures seamlessly in real time.

This process also allows you great control over masking, painting seamlessly over very disjoint UVs and blending.

The reason we chose this approach is simply a matter of scalability and control. We simply could not effectively paint the size and number of textures Mari does using direct paint.

</technical stuff>

I hope this helps and I encourage you to play around a little more.

Please feel free to drop support@thefoundry.co.uk (http://forums.cgsociety.org/support@thefoundry.co.uk) an email or register at www.paintmore.co.uk (http://www.paintmore.co.uk) if you need more help.

Jack




I've been hugely looking forward to this coming to Windows. :)
So I just downloaded the trial and installed it. Not knowing what to do I just loaded an object I was recently painting with Mudbox 2011. It has about 75,000 polygons.
So I was able to tumble around easily enough, but it froze for a few seconds after *every* brush stroke.

It looks great and I am planning on learning as much as I can about it and trying it out fully in the time I have.
But to be honest, Mudbox walks all over this particular object - no lag, no delay, and works flawlessly, but if Mari can't compete with that it won't be worth it.
Naturally I expect there to be issues with a first release, and I really hope I'm just doing something wrong.

Windows 7 x64
GTX 285
8 GB RAM
Intel Q9550 quad core (2.83 ghz)

[twosheds]

Hi Jack,
Thank you for the very thoughtful and detailed reply and explanation. :)
No there's no point in me sending the model - Mari is obviously doing its thing properly and I failed to mention earlier that's exactly what I was doing - paint, move, paint, move.

In this brief time however, I have learned a few new things about it and had better luck with my attempts since. I do understand more or less what you're saying, although it's a different workflow than I'm used to. Nevertheless, I trust it will be worth taking the effort to learn in order to fully evaluate. :)

Performance-wise, I'm not having any issues. The painting is lightning fast when I keep the camera in one position, and the lag when moving is only brief. Tumbling the model around is also like no effort at all and it "feels" like a very low poly object.

[Kel Solaar]

Any plans to support Ati Graphics Cards ?

KS

[forelle]

Any plans to support Ati Graphics Cards ?

KS

We're working on it at the moment. No eta I'm afraid but it is in the works.

J

[DuttyFoot]

We've had some teething troubles with the Wacom on Windows and are keeping a close eye on it. If you manage to recreate the problem could you let us know and we'll get it fixed. We'll keep looking at it from our end.

The best possible thing would be to screen capture a video of it happening, but I understand that this may not be possible.

Thanks for the feedback so far.

Please let me know how you get on otherwise. :)

i was trying to do a screen shot but the mouse cursor wasn't being captured at all. basically i could see the mouse cursor and brush cursor on screen at the same time. i went into the wacom setup and set my pen from mouse mode to pen mode and that fixed it. now i only see one cursor on the screen :)

[forelle]

i was trying to do a screen shot but the mouse cursor wasn't being captured at all. basically i could see the mouse cursor and brush cursor on screen at the same time. i went into the wacom setup and set my pen from mouse mode to pen mode and that fixed it. now i only see one cursor on the screen :)

Ok, thanks! We'll have a look at this from our side.

J

[PaulAdams]

Hi

Thanks for the reply. The GTX 285 seems to be similar specs to my Quadro 3800M. Can you let me know which driver version you're using? I can edit and paint on at least 4M polys and 400+ 4k textures on my machine. Any chance you could share the model with my so I could try it out on my machine?

J

Having read your post at the top of this page I think thats what I was/am experiencing rather than a problem with the app. Though it takes an age to load a medium res model, painting is fast until you move the camera, which is fair enough given your explaination above. Though does this not mean you have to be very clear about what you want to paint before hand? Workflow wise, it doesn't seem to be best adapted for fast and loose experimentation for look development if you have to wait 30seconds before you can tumble round the model or am I missing something?

[forelle]

Having read your post at the top of this page I think thats what I was/am experiencing rather than a problem with the app. Though it takes an age to load a medium res model, painting is fast until you move the camera, which is fair enough given your explaination above. Though does this not mean you have to be very clear about what you want to paint before hand? Workflow wise, it doesn't seem to be best adapted for fast and loose experimentation for look development if you have to wait 30seconds before you can tumble round the model or am I missing something?

It really depends on your work flow, the number and complexity of the textures you're painting, and your own personal style.

If you're waiting 30 seconds on a simple texture set up (1 or 2 4k textures) I think there might be a configuration issue. Even on my laptop I only wait a second or two on a set up like that. How full your cache disk is can have a big effect here.

That said, Mari is designed for high-level production texture painting rather than free and loose sketching. Although sketching and concept work is obviously a very important part of look dev, it is often not the bottle neck. This comes when you go from concept through to approved textures.

This can involve a large amount of detail work and iteration, coupled with a requirement for accuracy and control. This is where Mari excels. As I mentioned above, it may feel slower, but I've seen speed-ups from 3-10x in terms of going from blank textures to final approval (this is based off thousands of assets passing through look-dev).

As with all things, it's about choosing the correct tool for the job in hand.

[AlanW]

I personally prefer to turn auto-baking off. It's easier for me to just tap the "b" hotkey when I'm ready to bake paint. This allows me to more freely manipulate the paint buffer as well.

As for the speed of baking. I think this is more of a GPU driven task, but Jack would have to correct me there. I know when I upgraded to a new quadro, and put Mari's cache on a 500GB RAID0 Mari was really happy about it. My bakes are less than 1 second 90% of the time.

[forelle]

I personally prefer to turn auto-baking off. It's easier for me to just tap the "b" hotkey when I'm ready to bake paint. This allows me to more freely manipulate the paint buffer as well.

As for the speed of baking. I think this is more of a GPU driven task, but Jack would have to correct me there. I know when I upgraded to a new quadro, and put Mari's cache on a 500GB RAID0 Mari was really happy about it. My bakes are less than 1 second 90% of the time.

Hello,

It's a bit of everything really.



Fast HDs help the caching and data IO - SSD disks makes it fly.
Fast GPUs help the rendering
Lots of CPU cores help the data optimization
Lots of memory means there is a higher chance of data being available quickly.
Mari is designed to take advantage of everything you can throw at it (within user defined limits). For large projects the bottleneck is usually the HD, for smaller projects it in normally the GPU.

[AlanW]

Hello,

It's a bit of everything really.




Fast HDs help the caching and data IO - SSD disks makes it fly.
Fast GPUs help the rendering
Lots of CPU cores help the data optimization
Lots of memory means there is a higher chance of data being available quickly.
Mari is designed to take advantage of everything you can throw at it (within user defined limits). For large projects the bottleneck is usually the HD, for smaller projects it in normally the GPU.


Thanks for the info. I figured an SSD would be great for Mari's cache, but the 250GB+ variety are still quite pricey. I am curious about it though. Like what Mari's read/write ratio might be.

[forelle]

Thanks for the info. I figured an SSD would be great for Mari's cache, but the 250GB+ variety are still quite pricey. I am curious about it though. Like what Mari's read/write ratio might be.

Hi

You can actually combine multiple cheaper devices into a single cache by adding more than one cache location. Mari will stripe its cache over multiple devices easily. Because it is fully multi threaded this can have pretty impressive results, especially on traditional disks.

Each block of data you create will be written (at most) once and then read back when required. Because we do some very aggressive optimizations under the hood Mari won't write the same data to the disk twice. This is great as lots of textures contain large portions of empty space and repetitions.

Our internal debugging tools report, on a standard session, around a 1-20 write/read ratio depending on what you're doing and how big the project is. Just navigating around a project won't really write anything. But applying filters to the whole texture set will potentially, write lots.

I hope this helps

[AlanW]

Hi

You can actually combine multiple cheaper devices into a single cache by adding more than one cache location. Mari will stripe its cache over multiple devices easily. Because it is fully multi threaded this can have pretty impressive results, especially on traditional disks.

Each block of data you create will be written (at most) once and then read back when required. Because we do some very aggressive optimizations under the hood Mari won't write the same data to the disk twice. This is great as lots of textures contain large portions of empty space and repetitions.

Our internal debugging tools report, on a standard session, around a 1-20 write/read ratio depending on what you're doing and how big the project is. Just navigating around a project won't really write anything. But applying filters to the whole texture set will potentially, write lots.

I hope this helps

It does indeed. I wasn't aware that I could use multiple cache locations. When doing this, is there still the same recommended minimum size of each cache location, or just the total overall size?

Thanks again,
Alan

[forelle]

It does indeed. I wasn't aware that I could use multiple cache locations. When doing this, is there still the same recommended minimum size of each cache location, or just the total overall size?

Thanks again,
Alan

The cache size really just depends on the size of project you're working on. But, it is the combined sized that matters rather than the size of the individual disks. For large projects it is a good idea to keep the cache disk less than 50% used.

<off topic technical stuff>

The performance of metal disks (and some file systems) can degrade dramatically after they're around 50% full. I've seen some people create raid arrays of 500Gb disks with only the first 250Gb partitioned on each disk to increase the overall speed of the array. If you only use the outer edges of the disk, more data passes under the read heads per second, thus the average read speed will be higher than a drive in which the smaller, slower, inner tracks are used.

But if you're going to that much effort, SSDs all the way. :)

[AlanW]

The cache size really just depends on the size of project you're working on. But, it is the combined sized that matters rather than the size of the individual disks. For large projects it is a good idea to keep the cache disk less than 50% used.

<off topic technical stuff>

The performance of metal disks (and some file systems) can degrade dramatically after they're around 50% full. I've seen some people create raid arrays of 500Gb disks with only the first 250Gb partitioned on each disk to increase the overall speed of the array. If you only use the outer edges of the disk, more data passes under the read heads per second, thus the average read speed will be higher than a drive in which the smaller, slower, inner tracks are used.

But if you're going to that much effort, SSDs all the way. :)

Thanks again for the good info Jack. If I have any other questions I'll take it to the lists.

Cheers

[RobertFreitag86]

Hm I have a dual quad Xeon system with a Quadro FX 4800 With an Intel SSD 160 Gig.

and actually it's crashing when I try to load something, it doesn't matter what. Even the Demo files are not working :(

Here is what I do:

I start Mari.
Click on "create new project"
Then I provide the path for the "hammer.obj"
Then I check "Create" and "Import" for the Color map and import and provide the path for the hammer "color" map.

Then I click "ok" and it crashes.

It even crashes when I Try to not import any map, just load the model create the map with a solid color..

Can anyone confirm this?

Thanks
-Robert

[MasonDoran]

i am just curious if there is a way to paint symmetrically? ie: mirror the painting on the X axis.

[forelle]

i am just curious if there is a way to paint symmetrically? ie: mirror the painting on the X axis.

Not in the current version. It is VERY much on our to-do list though.

J

[twosheds]

Not in the current version. It is VERY much on our to-do list though.

J

Well that sounds great. :D

[forelle]

Hm I have a dual quad Xeon system with a Quadro FX 4800 With an Intel SSD 160 Gig.

and actually it's crashing when I try to load something, it doesn't matter what. Even the Demo files are not working :(

Here is what I do:

I start Mari.
Click on "create new project"
Then I provide the path for the "hammer.obj"
Then I check "Create" and "Import" for the Color map and import and provide the path for the hammer "color" map.

Then I click "ok" and it crashes.

It even crashes when I Try to not import any map, just load the model create the map with a solid color..

Can anyone confirm this?

Thanks
-Robert

We've certainly tested on this card. Can you let me know which gpu driver version you're using and if it is up to date?

support@thefoundry.co.uk will be able to help you with this as well.

J

[sforsyth]

I'm using a 16 x 3.07gHz core machine with 12Gb RAM and a Quadro FX 4800 card (Ver: 8.17.12.5912 from 26/07/2010) running on Windows 7, and it's unusable for me too. I bring up the sample blacksmith project, and even just rotating around the model is nigh on impossible. I'm waiting 2 or 3 seconds every time before it even responds. Even then, when spinning, I'm getting what feels like 2 or 3 fps. Is there something I should be doing?

[forelle]

I'm using a 16 x 3.07gHz core machine with 12Gb RAM and a Quadro FX 4800 card (Ver: 8.17.12.5912 from 26/07/2010) running on Windows 7, and it's unusable for me too. I bring up the sample blacksmith project, and even just rotating around the model is nigh on impossible. I'm waiting 2 or 3 seconds every time before it even responds. Even then, when spinning, I'm getting what feels like 2 or 3 fps. Is there something I should be doing?

Can you try turning vsync off in your GPU settings? There is more information about this in the release notes.

We know that this has caused massive slowdowns with some configurations.

The 4800 is the card Mari was originally written on, so I'm pretty confident it works. :)

[sforsyth]

Yep, that helps a lot actually, cheers for that!

[Burritoh]

Congrats on this release, Jack!

I have actually been rather surprised at well Mari works on lower cards like a GTX 260, with less than 1GB of ram. Perfectly usable on smaller projects. For people working professionally in CG, I don't think Mari's hardware requirements are all that steep, unless you're working on some really huge assets.

[SePu]

are u guys gonna work on a version for OSX? any chance to see that?

Thank You

[molman]

are u guys gonna work on a version for OSX? any chance to see that?

Thank You

This is something that has been brought up a few times and is under consideration. But atm its mainly Windows and Linux

[forelle]

are u guys gonna work on a version for OSX? any chance to see that?

Thank You

Mari uses OpenGL 3.0 and OS X only supports 2.x.

Until Apple update their GPU drivers there isn't much we can do. Sorry.

Jack

[jogshy]

Does it support ptex?

[earlyworm]

Jack could probably give you a more accurate idea of when Ptex support will be available - but it is coming - along with Disney's Paint3D tech (which from what I understand offers some neat procedural paint stuff).

http://www.thefoundry.co.uk/articles/2010/07/20/98/the-foundry-gain-access-to-paint-3d-technology/

[ice-boy]

Jack could probably give you a more accurate idea of when Ptex support will be available - but it is coming - along with Disney's Paint3D tech (which from what I understand offers some neat procedural paint stuff).

http://www.thefoundry.co.uk/articles/2010/07/20/98/the-foundry-gain-access-to-paint-3d-technology/something like this ?
http://www.disneyanimation.com/library/TexSynProd.pdf

[molman]

Does it support ptex?

We are currently working with Disney to put this feature into Mari. Perhaps early next year.

[LoudNoises]

Regarding non-quadro cards and Mari, is the size of the framebuffer more important than the number of cores and processing speed? For example would a gtx 460 overclocked to have a 2gb framebuffer be a better option than a gtx 580?

[ice-boy]

Bad Robot's Brandon Fayette and Jake Raymor demo MARI
http://www.youtube.com/watch?v=80ZvASS9zng

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.