915 replies to this topic

[AbnRanger]

I did a quick test using the increase brush on a cached proxy (testing to see if it was editable or frozen), and I was blown away with the sculpting speed. It has to be every bit as fast as Mudbox or ZBrush.

I think Andrew may have stumbled upon something here...

[Andrew Shpagin]

Oh really? Wouldn't this be a wasted feature?
I thought that this could get a way to do Surface-Sculpting and Voxel-Sculpting in one Room.
On a cached mesh I could for the first time smooth with huge brushes which were unusable both
in Voxel and in Surface-Mode thus far...

Btw: it is possible to sculpt on a cached mesh and merge to the paint-room without previous uncaching...

I absolutely agree that multiresolution will be more then useful. And it will be logical next step. Caching is just first step to this long-long-waiting direction.
I hope multiresolution will be there until 3.4 (but I can't promise, all depends on how successfull experiments will be). But in general I assume to do it in so way (description is simplified):

1) If model is in voxel mode then after returning from cached state the cache:
- IncRes required amount of times
- Light extrude in negative direction
- Compose original volume and extruded cache with addition
- Light extrude in positive direction
- Intersect original volume with extruded cache

2) If cache is in surface mode (and was there from the beginning) -
- calculate weights correspondence between old mesh and lowpoly cache mesh using distance weighting.
- apply deformations of low-poly mesh to high poly mesh using that weights.

Second way is slightly more realistic and closer to original multiresolution conception.

[Taros]

3.3.02 uploaded (Mac+Win are there, Linux - soon)

- I made support of caching of voxel volumes. You may cache any vol to disk and leave only low poly proxy of the volume. In so way you can preserve memory and increase speed of sculpting.
- The problem with SpaceNavigator drifting on OSX finally solved. Some details about OSX & Space Navigator drifting problem - http://bit.ly/bi9Och
- Unwrapping of big meshes in UV tool improved - muh better stability and speed of unwrap.
- Solved problem from the previous build - resizing texture clears layers contence.
- The problem with edit projection in orthographic mode solved - http://bit.ly/b03gr8

I know everybody is happy about the new cache function and the first developement to accelerate voxels, but... The little 3rd point in the upper update list is very important too. Why? I give you an example: I have a model, that needed every time 45 Minutes(!) to unwrap, it has over 2 millions polygons. A lot of time to wait for unwrap. This was in the previous versions...

Now the same mesh needs just 2 MINUTES! This is more than 22[edited] times faster, than before. And I have a lot of highres models. I hope you can imagine, what this means for our work with high poly meshes.

Good work, Andrew. I am very curious for the brush optimisation, that you have on your plan, too.

Best wishes
Chris

[haikalle]

Is that like over 22x speed up. That's quite amazing. Andrew, could you fix my car (volvo).

[amcmahon]

Andrew,

I don't seem to recall having this issue before but it's been awhile since I've tried it so I can't be 100%. When exporting an obj from Voxels and exporting a retopo mesh wrapped to that voxel mesh I get 2 very different sized meshes. Is there an option or workaround that I'm missing to export a voxel (high poly) mesh and a retopo mesh the same size? The purpose for this was to bake out additional maps in xNormal. I checked the scale in other apps such as ZBrush and 3dsmax and they are consistent in that they come out different sizes. The retopo mesh is a good 3x larger.

[polyxo]

I absolutely agree that multiresolution will be more then useful. And it will be logical next step. Caching is just first step to this long-long-waiting direction.

Hi Andrew,
thank you for your reply! I am glad that multiresolution is on your Radar
However:

Doesn't caching maybe give you the chance to no more having to differenciate
between a dedicated Voxel-Workspace and a Surface-"Sub-Room"?

I personally am far more interested in a solid and fast Voxel-toolset in order
to freely create Volumes than in High Frequency Detail (like Pores and Micro-Wrinkles).
It would be awesome to get all this work done inside just one workspace without
having to change between Voxel - and Surface-Workbench.

Is there a chance that we can toggle an object (or unmasked parts if it)between an
acurate Voxel-representation and a lossy (but blazing fast) Proxy-representation
with a Hotkey while staying inside just one Workspace?

[Polygoon]

Excellent work Andrew and best wishes for success with your experiments. From the dedication you have shown I'm sure you will overcome anything that is possible.

[splodge]

I would rather get away from the term 'caching' and instead use the term 'Proxy' or just 'Lo Res'. The caching process shouldn't really concern be of too much concern to the end user. The caching and freeing of memory should be a bonus side effect of the proxy. The main feature of having a proxy object should be that 3D Coat can display the proxy when the user pans or rotates the camera, resulting in better frame rates.

This is basically how things work in ZBrush or Mudbox, you can switch to a lower subdivision in order to improve frame rates or for editing the low detail version of the object. Switching to a lower subdivision will give ZBrush the opportunity to cache the higher subdivisions, but only if memory is getting low.

Memory management should be invisible to the end user.

[AbnRanger]

I know everybody is happy about the new cache function and the first developement to accelerate voxels, but... The little 3rd point in the upper update list is very important too. Why? I give you an example: I have a model, that needed every time 45 Minutes(!) to unwrap, it has over 2 millions polygons. A lot of time to wait for unwrap. This was in the previous versions...

Now the same mesh needs just 2 MINUTES! This is more than 5 times faster, than before. And I have a lot of highres models. I hope you can imagine, what this means for our work with high poly meshes.

Good work, Andrew. I am very curious for the brush optimisation, that you have on your plan, too.

Best wishes
Chris

I agree....I was experiencing similar issues a few weeks ago, and am glad that has been addressed. Still having niggly issues in the Retopo room from time to time, where it seems like it just wants to fight....but on the whole, this has been a good week.

I would rather get away from the term 'caching' and instead use the term 'Proxy' or just 'Lo Res'. The caching process shouldn't really concern be of too much concern to the end user. The caching and freeing of memory should be a bonus side effect of the proxy. The main feature of having a proxy object should be that 3D Coat can display the proxy when the user pans or rotates the camera, resulting in better frame rates.

This is basically how things work in ZBrush or Mudbox, you can switch to a lower subdivision in order to improve frame rates or for editing the low detail version of the object. Switching to a lower subdivision will give ZBrush the opportunity to cache the higher subdivisions, but only if memory is getting low.

Memory management should be invisible to the end user.

I don't have any issues with framerates in 3DC, so I don't personally see the benefit of showing a proxy when the camera moves about the object...not yet anyway.

ZB and MB have different issues than those present in Voxel sculpting. Caching to disk manually is a END USER tool, to manage memory in the scene...not a background memory function. I think ultimately, it would be good to have anything hidden to be cached automatically (in the background so that there is no waiting needed before moving on to the next task).

However, as it stands, I like Andrew's implementation of this feature and think it's a big step in the right direction

[artman]

Andrew,

I don't seem to recall having this issue before but it's been awhile since I've tried it so I can't be 100%. When exporting an obj from Voxels and exporting a retopo mesh wrapped to that voxel mesh I get 2 very different sized meshes. Is there an option or workaround that I'm missing to export a voxel (high poly) mesh and a retopo mesh the same size? The purpose for this was to bake out additional maps in xNormal. I checked the scale in other apps such as ZBrush and 3dsmax and they are consistent in that they come out different sizes. The retopo mesh is a good 3x larger.

Export Object from voxtree is broken,Andrew tried to fix it but it didnt work.
To get matching scale with retopo export you need to export your voxel object using either
Export Scene or Export Pattern from voxtree.
(don't worry,export pattern works exactly like a normal export...you even get decimation control )

[Taros]

Is that like over 22x speed up. That's quite amazing. Andrew, could you fix my car (volvo).

umpf... yep... that's right... oh dear. Have worked to much, I guess.

[artman]

Just tried caching a 16mil layer to level 3 (x8) and used Big move brush radius for quite a few strokes and merging time was below 4 minutes.
Strokes with such a big radius like that would have generated at least 1 hour of merging time in previous way.
Huge noticable improvement.Transfer of changes done to proxy is very impressive.

[amcmahon]

Export Object from voxtree is broken,Andrew tried to fix it but it didnt work.
To get matching scale with retopo export you need to export your voxel object using either
Export Scene or Export Pattern from voxtree.
(don't worry,export pattern works exactly like a normal export...you even get decimation control )

Sweet. Thanks Artman, it worked.

[splodge]

Just tried caching a 16mil layer to level 3 (x8) and used Big move brush radius for quite a few strokes and merging time was below 4 minutes.
Strokes with such a big radius like that would have generated at least 1 hour of merging time in previous way.
Huge noticable improvement.Transfer of changes done to proxy is very impressive.

Artman, there are no transfer of changes. Editing the proxy has no effect on the main object. When you toggle the cache button the original object will be reloaded and changes to the proxy will be lost.

[Javis]

Artman, there are no transfer of changes. Editing the proxy has no effect on the main object. When you toggle the cache button the original object will be reloaded and changes to the proxy will be lost.

I'm having this happen too. It wasn't happening at all before for hours of testing. Now it wont work and has the above results.

[philnolan3d]

Wait, am I understanding that some people are seeing changes made to the cache proxy get applied to the high res model? In all of my testing so far I've never seen that happen.

[Javis]

Wait, am I understanding that some people are seeing changes made to the cache proxy get applied to the high res model? In all of my testing so far I've never seen that happen.

Yep, that's the idea.

It was working for me.

[philnolan3d]

Well if that's the way it worked I'd be very impressed, it never did that for me so I had no idea.

[Javis]

I was messing with 3.3.02 before it was released, for about 2 hours, and had no issue with it.


Unsure why it's not working now... Hmm.

[digman]

It was not working as described for me either on Win32 bit non_cuda 3.3.02. Linux version has not been updated to 3.3.02 yet...

Anyway, part of Andrew's quote a few post up is exciting news.

Quote:
"I absolutely agree that multiresolution will be more then useful. And it will be logical next step. Caching is just first step to this long-long-waiting direction.
I hope multiresolution will be there until 3.4 (but I can't promise, all depends on how successfull experiments will be): "