Would hollowing out my models save memory? — Oculus
New to the forums? Click here to read the "How To" Guide.

Developer? Click here to go to the Developer Forums.

Would hollowing out my models save memory?

P3nT4gR4mP3nT4gR4m Posts: 1,700 Valuable Player
edited December 2016 in Oculus Medium
Not sure how these signed distance field thingmybobs work but it's something like a 3d grid filled with "voxels", right? Hollow models = less voxels, right? Or is that not how it works?

Comments

  • ThmoasThmoas Posts: 318
    Trinity
    edited December 2016
    Try it but I would expect the lowest memory is with the lowest model detail. Hollowing out creates more model detail.
  • nalex66nalex66 Posts: 4,530 Volunteer Moderator
    Yeah, I think that would make it worse. Empty or full space shouldn't take up any memory, it's the surfaces between them that do it. hollow models = twice as many surfaces. That's why any attempt at realistic hair ends up being a total memory hog--huge amounts of surface area in a small space.
    i7 5820K @ 4.25 GHz | EVGA GTX 1080 SC | Gigabyte GA-X99-UD4 | Corsair DDR4 3000 32 GB | Corsair HX 750W
    Corsair Hydro H100i | Samsung SSDs: 860 Evo 1 TB, 850 Evo 1 TB, 840 Evo 1 TB | Seagate BarraCuda HDD 3 TB
  • Nobbs66Nobbs66 Posts: 722 Poster of the Week
    As @nalex66 said, doing that would likely kill performance due to the increased poly count
    i7 5820K @ 4.4ghz | R9 Fury Tri X @ 1150mhz | 16GB DDR4 2133mhz
  • P3nT4gR4mP3nT4gR4m Posts: 1,700 Valuable Player
    edited December 2016
    Ahhhhh. Good point, so we're dealing with surface area? A lot of my stuff is accidentally hollow (and complexly hollow to boot) a result of the way I scribble in the forms. Instead of hollowing out, I should go back and fill in the gaps.

    *Edit* Hold on tho, it can't be that simple. Medium is definitely storing the interior (non surface) mass. Lay down a blue stamp, then do a bigger one at the same origin in red. Cut it in half and you'll see both colours through the cross-section. It must be holding that data somewhere.

    Maybe hollow mesh will save system ram at the expense of gpu-ram and filled mesh will save gpu at the expense of system ram?
  • robdoodrobdood Posts: 19
    NerveGear
    @P3nT4gR4m that definitely alludes to it being a better idea to have hollow models, then.  I had a feeling it worked that way! 
  • nalex66nalex66 Posts: 4,530 Volunteer Moderator
    edited December 2016
    I think it still deals in surfaces that surround closed spaces, though. The layer is a matrix of tiny cubes that store a value, '0' = empty, and any cube that a surface passes through stores a decimal value that indicates distance from the center of the cube to the surface. I suspect that values are not stored for internal volumes, so that part of your model doesn't consume memory. If that's the case, then the hollow model still has much more surface area and thus consumes more memory. Or, maybe interior volume stores a simple '1', which consumes less memory than a float value.

    It may be worth trying it and comparing file size and RAM load between a scene with a hollow model and a scene with the same model with a solid interior.

    It's interesting that the internal object is preserved in your example of two different coloured stamps. It may be that both surface definitions are kept because of the different colours, to maintain the integrity of a model made with multicolour clay. I guess that gets complicated as you start blending, smoothing, etc. with different colours of clay, so maybe there is more stored data for internal volumes than I thought.

    Here's an experiment to try: How does the file size or RAM load differ between a scene that contains one large stamp, a scene that contains one large stamp that fully encloses a smaller stamp of a different colour, and a scene that contains one large stamp that fully encloses a smaller stamp of the same colour?

    Of course, the Undo buffer may obfuscate efforts to determine memory load from a model... is the Undo history preserved in the save file?
    i7 5820K @ 4.25 GHz | EVGA GTX 1080 SC | Gigabyte GA-X99-UD4 | Corsair DDR4 3000 32 GB | Corsair HX 750W
    Corsair Hydro H100i | Samsung SSDs: 860 Evo 1 TB, 850 Evo 1 TB, 840 Evo 1 TB | Seagate BarraCuda HDD 3 TB
  • P3nT4gR4mP3nT4gR4m Posts: 1,700 Valuable Player
    nalex66 said:

    Here's an experiment to try: How does the file size or RAM load differ between a scene that contains one large stamp, a scene that contains one large stamp that fully encloses a smaller stamp of a different colour, and a scene that contains one large stamp that fully encloses a smaller stamp of the same colour?

    Of course, the Undo buffer may obfuscate efforts to determine memory load from a model... is the Undo history preserved in the save file?
    My thoughts exactly, I'm sure there's a ton of other complicated stuff in ram that would muddy the waters. Hopefully one of the devs will chime in and save us the guesswork.
  • nalex66nalex66 Posts: 4,530 Volunteer Moderator
    Yeah, I figure if one uses a really complicated stamp, maybe the differences will show through the white noise. Each scene started from a new boot of Medium, same stamp, no Undo, same process as much as possible to get a good controlled comparison.

    I might experiment a little if I get time tonight, or else next week after Christmas visiting is finished. (Gotta go spend a few days with my wife's family, then over to see mine on Christmas day, then 8 days at home to play with my toys!)
    i7 5820K @ 4.25 GHz | EVGA GTX 1080 SC | Gigabyte GA-X99-UD4 | Corsair DDR4 3000 32 GB | Corsair HX 750W
    Corsair Hydro H100i | Samsung SSDs: 860 Evo 1 TB, 850 Evo 1 TB, 840 Evo 1 TB | Seagate BarraCuda HDD 3 TB
  • kojackkojack Posts: 5,291 Volunteer Moderator
    There's two main things to think about here: memory used to store the SDF (Signed Distance Field) and memory to store the mesh.

    The mesh is the easy one. It's an implicit surface, so the mesh itself isn't what we are editing, it's generated from the SDF as needed. Every triangle needed in the mesh will add to the memory use. Hollow objects will have a higher triangle count because the interior surface still needs to be generated, whether you see it or not. In the example above of cutting through a two colour object, triangles are only generated where air touches solid. The mesh doesn't care about the inner mass if there's no air touching it (requiring triangles as the boundary).
    So hollow objects should use more memory for the mesh, and will affect the exported mesh size and the rendering performance).

    Now for the SDF. This is trickier because we don't know if they do any tricks involving spatial partitioning (I'll come back to this). If it's a simple raw SDF, then solid and hollow make no difference. An empty layer and a solid layer use the same ram. This is because the SDF is a giant grid storing maybe 8 bytes at every grid cell. (I guess 8 bytes due to 4 bytes for a float distance value and 4 bytes for a 32bit RGB colour). If the grid is 1024x1024x1024, then that layer uses 8GB of ram no matter what you put in it, air and clay are equally expensive.

    Spatial partitioning is a way to divide up a region based on content. Common algorithms include BSP (binary space partition, used for maps in Doom, Quake, Unreal, etc), Quadtree (mainly 2d maps), Octree (3d), KD Tree (popular with raytracers), etc. Medium would benefit from Octree or KD Tree. The idea is that large regions of the same value (like air that's far from a surface, or a large blob of clay with 1 colour) can be optimised down to use less ram (for example, if the top left corner of the layer has only air, then don't store individual air grid points, just flag it as empty).





  • surtsurt Posts: 22
    Brain Burst
    edited December 2016
    Medium appears to be chunk based from the mesh output. (built out of smaller fixed-size blocks of voxels)
    Layers have a finite size and uniform resolution.
    From this I presume they are using a simple fixed-size 3D array of chunks.
    If that's the case then any fully empty chunks shouldn't need to be allocated, but non empty chunks will need to be fully allocated. (chunks might be preallocated in a cache for faster chunk creation, that shouldn't cause memory problems though)
  • bhsharpbhsharp Posts: 34 Oculus Staff
    @surt - as of 1.0.1, exported OBJ meshes should not have split seams anymore - let me know if you're still seeing them split up. But yes, good inference - those seams were aligned on the size of our SDF blocks.

    @kojack - good analysis. We don't spatially *partition* in the sense of octrees or anything (in practice wouldn't yield much perf benefit for anything we do, and just takes a little memory + bookkeeping), but the SDF is stored sparsely, so we don't allocate a block until you do something with it.

    That said, I'm pretty sure right now we don't reclaim blocks when you empty them.

    So, TLDR: Sculpting a model that is hollow *in the first place* will save you some memory (probably less than you expect unless it's a really large interior volume.) Sculpting a model solid and then hollowing it out will not save you any memory.
  • P3nT4gR4mP3nT4gR4m Posts: 1,700 Valuable Player
    Thanks for the clarification @bhsharp. There's workflows I can think of where I could end up modelling the skin and fine surface detail on a separate layer then ditch the rest. If you imagine something humanoid where the skin is a centimeter or so thick at most, I'd probably be saving a significant amount of volume by doing this as a last pass.

  • bhsharpbhsharp Posts: 34 Oculus Staff
    With the 1.0.2 patch we just released you can confirm your way through the low memory stuff. So the deal with that is that Windows warns us when the *physical* memory is getting low. You can push your way through that if you want, especially if you're running other memory-hungry apps, because Windows will just page them out and Medium will be fine. We make you confirm through it because you may get hitching and frame drop while the paging happens, but otherwise perf should remain alright.

    That said, if you're rocking an 8GB rig, yeah, you're gonna be limited. Back at Bungie all our dev machines for Destiny were 32GB base and I'm pretty sure some artists got 64+. Content takes memory.

    Clearly there's more we can do here over time. Like, we could page out layers once they've been invisible for a while, or if we figure out some way for you to tell us that you're going to leave them invisible a while. Half the work is figuring out good UX design for it, half is the work of actually freeing up the memory and being able to reload it when we need to. It's all just work, and we only have so many fingers to type with.

    As for the hollow thing, the way our SDF works, we store data a few voxels out from the surface, too, so again, hollow models won't save as much as you expect (mentally inflate the model by a few voxels and that's what we need in memory.)

    I hollow out models primarily for 3D printing to save on resin, since my Form2 can print hollow shapes without filling them in. And actually hollowing out models to a nice consistent wall thickness is kind of hard in Medium right now, it's something I want to think about improving. But less for memory, more for making shells.
  • danknugzdanknugz Posts: 1,988
    3Jane
    i got the warning today in medium about memory, thanks for the info
    A: Because it messes up the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on forums?
  • kojackkojack Posts: 5,291 Volunteer Moderator
    bhsharp said:

    @kojack - good analysis. We don't spatially *partition* in the sense of octrees or anything (in practice wouldn't yield much perf benefit for anything we do, and just takes a little memory + bookkeeping), but the SDF is stored sparsely, so we don't allocate a block until you do something with it.

    That said, I'm pretty sure right now we don't reclaim blocks when you empty them.

    Cool. I had a read through the python scripts and shaders in the medium directory and saw mention of blocks, so I was guessing it was something like that.

  • surtsurt Posts: 22
    Brain Burst
    It'd cool if we could get an option for chunk boundary visualisation so we can take that into consideration when editing.
  • RoasterRoaster Posts: 1,052
    3Jane
    I was trying to upload a sculpture but it kept responding upload failed. I could see upload traffic on the pc, so I know it was trying, but seemingly the server wouldn't have it.  Tried maybe eight times over two days.
    It was a two-layer laminate, with a hollow center portion and a skin on top of that, so on a whim I erased the part of the core that was concealed and the upload was successful. 
    It wasn't due to empty layers this time as they had already been eliminated.

    Question to devs ... are there certain limits or restrictions on uploads? Size, memory, or whatever?
    i7-5820K @ 4.2Ghz, water cooled, Asus X99-Pro USB 3.1, 48 Gb DDR4 2400, Samsung 950 pro M.2 SSD, GTX 980 Ti SC, 750w psu
Sign In or Register to comment.