Deleting part of a model persistently and distributing a scene that uses it
dgatwood
Posts: 23
I'm running into an issue that I don't know a good way to solve. I'm trying to develop some custom scenes for public (probably free) distribution that incorporate paid DAZ models into a more complex scene. Obviously anyone using those scenes would have to buy the underlying DAZ models to open the scene, which is fine. But distributing such a scene requires that every asset (models, materials, etc.) be either used as-is or created from scratch.
Unfortunately, I keep running into the same problem over and over: a lot of the commercially available DAZ models combine large chunks of a scene into a single object with a dozen or more materials, and futher combine all of the mesh surfaces with a similar appearance into each material. So:
- I can't delete the individual parts, because a huge chunk of the scene is in a single object.
- I can't remove undesirable parts by making their material transparent, because I would also lose parts of the scene that I want to keep.
- I can't create a custom copy of the object with removed faces, because I would have no license to distribute that modified model.
- I can't easily create custom materials presets, because either A. they use shaders or B. I would have to include parts of the original material, which would have the same copyright/licensing problem as distributing a partial copy of the model.
For example, every Daz bathroom set that I own is built in such a way that you cannot keep just the shower metal parts by themselves. Modern House 2 uses a single material for both the sink drain and the shower chrome, so you can't hide one without the other, and the whole thing is a single object. Girls Dorm Room combines the shower handles with other elements that would be inappropriate in the context where I plan to use them, again with a single material for both. Z Shower and Lavatory Environment uses a single surface for every copy of the shower, so you can't reduce the number from 5 down to 3 or increase it to 6 or whatever. And in the Z Shower set, the drains are all a single surface, so you can't even change the size of the room, because the drains are in fixed positions relative to each other even though they are on opposite sides of the room. The same is true for the lights (though it's easy to find models for lights — floor drains, not so much).
All of this would be easily fixable if the geometry editor allowed proper nondestructive editing on a per-instance basis, but instead of that behavior:
- If you hide faces/vertices, it hides them in *every* instance of an object, so you can't (for example) have two instances of the same object and hide faces in only one of them. They disappear in all other copies of that model in the same scene. They also don't stay hidden; closing and opening the file causes them to reappear.
- If you delete faces, you have to save the result as a new model, which I would have no right to distribute, so there's no good way to distribute a scene that uses an edited model.
This seems like it is the sort of thing that should be relatively easy to do, but I'm not seeing any signs that it is even possible short of making people run a script every time they open the scene to hide a bunch of faces, and even that won't work if you need an unmodified instance of the object (because hiding faces hides them in every copy).
I mean maybe, maybe it might be possible to create a script that makes a copy of the original model, deletes the undesirable faces, and saves it, so that folks obtaining the content could run that script once and close and reopen the scene... but ugh.
I have the same problem with walls of buildings in other models. For example, FG School (ignoring the problem that the walls are paper-thin) uses a shared material and object for the pillar in the cafeteria, the walls in the cafeteria, and the bottom part of the counter. So I can't fix the flaw where there is no door between the area behind the counter and a kitchen (do workers climb over the counter?) without building new counters and a new support post. (I can probably fix those with primitives, so no big deal, but you get the point.) I'm literally running headfirst into this problem over and over again.
Ideally, I'd love to see a solution that lets me show or hide the portions of a scene that fall within the bounds of another object, which could be transparent. That would solve two problems, if it were sufficiently powerful — this and the problem of filling an arbitrarily shaped object with water. Create a cylinder primitive, use a water shader, and constrain the primitive to the intersection of the interior of the container plus an invisible box that excludes the upper part of the container, and you're done. But I'm guessing there's no support for any complex nondestructive multi-object operations like that at all other than the built-in clothing avoidance algorithms.
Any better suggestions? (I mean, other than trying to find shower head and shower handle and floor drain models that aren't so hard to reuse?) Some way to morph parts of the scene out of existence, perhaps?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Also tried creating a surface, though I assume that probably has the same problems as other geometry editor operations. When I created surface with a subset of faces from one object while a second instance of that object is visible, the faces in the second object immediately disappeared. Then, when I unselected the first object, I got an immediate crash. This is 100% reproducible.
Morphs also don't work, or at least not when created with Blender.
I'm not sure if the vertex order is changing or what's happening, but the behavior I'm seeing isn't even remotely usable. Maybe I'll see if FreeCAD can do a better job.
Also, I keep forgetting to choose the base mesh resolution, and it fails, which wasted a lot of time. :-(
Yeah, Blender is messing up the vertex order. If I hand-edit the obj file and change a few hundred vertexes to all be at 0,0,0, I get the expected behavior. Looks like a Blender bug.
If anybody runs into this problem, Blender has a really annoying open bug:
https://developer.blender.org/T68058
where by default, it destroys the vertex order both during import AND export. So you have to explicitly open a "Geometry" disclosure triangle and tell it to keep the vertex order during import, then check a checkbox to preserve it on export. Otherwise, your morphs will be garbage.
Now that I've figured that out, I have a working approach. Basically, I morph the undesirable bits into a tiny ball about a millimeter across and hide it inside one of the parts that I want to keep.
If the parts you want to hide belong to a figure a GeoGraft might work - you probably don't need more than a single polygon if there are going to be no holes needing capping, just load/create the mesh and run the Transerfer utility to turn it into a fitted figure, then with the Geoemtry Editor select the parts you want to hide, right-click in the Viewport>Geometry Assignment>Set AutoHide Faces for Attachments, and select the new fitted item you just made (menu names from memory). Loading the new figure will then hide the parts you specified (and, unlike a morph or transparency, will not send them to the render engine).
In this case, I was hiding one out of five shower heads in a wall of showers and, in one case, moving two of the other shower heads outwards. Then, I did the same thing for five of the ten floor drains. Then, I did the same thing for the groups of glass dividers.
The approach I ended up with is probably a bit inelegant, but it is working. I exported the object in Blender, modified it, pulled it back in with Morph Loader Pro, and applied the resulting morph. I then confirmed (by moving the modified .obj files aside and loading the scene from scratch) that the morph is getting stored as part of the scene rather than being applied from the modified object in any way, so that meets my requirement of not having to distribute a modified copy of somebody else's model.
Anyway, to make a long story short, my school (based on FG School) now has locker rooms where the classrooms were (adjacent to the gym as locker rooms should be) and emergency lights in the gym (though I still need to design or find safety cages). I've also built a beautiful two-story band room with glass rails around a partial balcony (and an attached office), made mostly out of Tesla3dcorp High with a bunch of wall and floor and ceiling pieces from Room Creator 2, folders full of music on the desk with custom skins on the folders from "Interiors the classroom", etc.
Now, I just need to add a kitchen to the cafeteria by morphing the back wall out of existence and merging parts of the kitchen from Moonshine Diner, put the FG School classrooms (which I cloned before turning them into locker rooms) somewhere, build a proper shower room for the pool, merge various other parts of Tesla3dcorp high as additional classrooms, build out the second floor, add the elevator interior from Elevator Hallway, put together some other classroom interior sets.... Eventually, this is going to be an amazing set.
well, I was going to start a new discussion.. but dgatwoods comment about the geo editor is what I was going to post.
I though I had geo editor whipped by renaming surfaces (remember many are named default by default.
But in this picture there are three cube base shapes
I gave them different names and renamed the surface on the one I edited.
To no avail Geo deleted the same faces in each one... and the other two were hidden.
---
My answer as usual will be to open another instance of daz edit the cube then rename it and save it as an object reimport it and then save it as a subset and then bring it into the scene with the other ones that I wanted to stay cubes.
Basically ... you just start building from scratch.. this happened while I was building the base for an ice cream fountain to put in back of the cafe which I've built over the years.
-----------
And if anyone knows how to avoid this multiple editing issue please clue me in.
There can be only one instance of the basic asset in a scene - you can't have two Gensis 8 Females with different surface names, for example. If you want two pieces with different groups then you need to ensure that they are not using the same asset.
you're talking in terms of using the geo editor right?
Or do you mean instances ... because they weren't instances they were duplicated objects or does the internal daz structure consider anything that is the same basic object even with different names and surfaces as the same object like it was an instance?
---
If I have an object (wavefront) of a cube will daz track them differently because they're not a daz cube?
DS has saved the "cube" asset somewhere. If you import a new cube and save it (although identical) it will be saved to a different location, i.e. not the same asset.
Yes, instances wasn't the ideal word to use - but al the things in the scene are pointing to a separate entity that defines their shape, UVs, groups and so on. Editing with the Geometry Editor is mofdying that geometry asset, which means that every node that calls it will change.
My bad. It is closed. That's even more depressing. It violates pretty much every set of human interfaces guidelines ever written, because it is a destructive behavior (the ordering of vertexes is permanently lost) that is entirely silent. It is not obvious when you import it that the vertex order changed, there is no warning message, and the default option is not the non-destructive option. As a result, it is very easy to import something into Blender, spend an hour or more working on it, and only discover at the very end of the process that your effort was wasted because you forgot to check that checkbox on import an hour earlier.
That checkbox should have been turned on by default. Or better, it should be called "Optimize vertex order", and should be off by default. Make the same of the setting give some hint about why you would check it, and make the default behavior be nondestructive.
The new experimental importer apparently does the right thing by default, so I guess this will eventually be fixed when that becomes non-experimental. *sigh*