Merging surfaces and removing unneeded vertices

stitlownstitlown Posts: 276
edited March 2023 in Hexagon Discussion

Hi all,

I use Hex fairly extensively for morphs - ie taking an existing mesh and just pushing and pulling it without altering the vertex / edge / surface count.

But ATM I'm trying to create a "bridge" or "adaptor" between two different models and that requires me to add in vertices and edges and merge surfaces then remove superfluous vertices. It's critcal that the UV mapping both be preserved and not be unduly distorted (eg welding one verted to another will distort the UV mapping).

Are there Hex tools to merge two surfaces (ie remove an edge without destroying the UV mapping) and to dissolve a vertex (ie join two edges at their common vertex into a single edge, again not destroying the UV mapping)? I can't seem to find those, although I do have some recollection of a dissolve command somewhere (but maybe that's a different application).

The screenshot might help explain what I need to to. In it you can see one quad has been split into two triangles.  I now want to merge one of those triangles with its adjacent quad, then remove the unneeded vertex so I now have a triangle with it's half of the original quad's UV map and a new, larger quad (albiet not very square in shape) that has the UV mapping of the other half of the split quad PLUS that of the quad it was merged with. Easy-peasy in my chosen other modelling app, but ???? in Hexagon.

I have to declare I've never been a Hex fan, other than for morphs, and it's not finding simple operators like these that have made me not a fan, so if there are these tools, I'd love to find them and master them.

Cheers, Lx

Screenshot (470).png
1436 x 888 - 69K
Post edited by stitlown on
«1

Comments

  • atoxicatoxic Posts: 130
    edited March 2023

    Hi. Answer : NO. I found no way to get rid of hidden faces in HEX and started a thread some time ago (Get rid of unused faces in an object ?).
    Unfortunatley there is no function in HEX to delete this facets, you have to delete them manually.

    For the second part, welding meshes, there Average Weld in the Tool Bar. This function will merge all points which are locacted in a given radius. You can adapt the value for this radius to get the best results.
    BUT: if you use Weld this shredders you UV map. (sometimes even the tessalation of the items) and you have to create new UV maps after the objects have been welded.

    As you said those are tasks for other modelling programs

    Nice Days ans NIce Renders

    Post edited by atoxic on
  • stitlownstitlown Posts: 276

    Thanks atoxic for confirming what I seemed to be finding.  Really puts a downer on Hex for me.

    In case others read this thread, and are looking for their own work-arounds, here's a quick summary of what I do.

    I use AC3D as my modeling tool. Might not be the worlds best but I find it very intuitive and fast. AC3D, Hexagon and DAZ all store their .obj objects in different vertex orders, so it's never as simple as work in one, export and re-import into the other. Even a base geometry update of a mesh in DAZ cannot be done from a Hex export.  In all instances the work flow has to be import any model into DAZ and export it again from DAZ if you wish to re-import it into an exitsing DAZ model in some way (morphs, geom updates, UV sets, blah, blah, blah). The exception is using the Hex bridge for DAZ morphs where, provided there are no "count" changes to the mesh (vertices, edges, faces) the bridge correctly re-casts the hex model into the DAZ vertex order.

    For a base geom update sculpted in Hex, I bridge back to DAZ as a prop, export the prop as an .obj then used that exported .obj to do the base geom update.

    Klunky, but at the end of the day, it works without mangling the model.

  • 1. I see no image attached to the 1st post.

    2. One can build a bridge between 2 objects without killing the uvmaps ... IF one makes that bridge as a geograft item. Gets a little tricky if making it a geograft for 2 objects.

  • stitlownstitlown Posts: 276

    Ooops. Pic now added.

  • To make a geograft of this 'bridge' you would require a "loop" of mesh from the figures to be bridged. I recolour loop mesh red to see it in Hexagon [it must not change location]. So one would have red, blue, red.

    Kill the triangles, add several more lengthwise tess lines.

    I know once upon a time I made a joiner between 2 figures however there was a lot more mesh to choose from than there is from your example {I'm making something of an assumption as to what you're hoping to bridge, good luck}

    Thing is a geograft starts out like a clothing figure, so it'll only be 'fit to' one of the two figures.

    Then somehow the 2nd figure needs to be attached ... and off the top of my head there appears no answers. Experiment and good luck.

    If you're willing to redo the uvmap on the smaller figure; then only red ; blue is needed, join the bridge to the larger figure but before doing all that, have this new mesh attached to the smaller figure. And redo the uvmaps. It's a task in itself; but one can remake the uvmap to be like the old one was so that the textures match. Give yourself a day or so to match line by line ;-) And of the area of the bridge, have the surface areas there matched to whichever uvmap set it makes sense to use.

    Wouldn't it be nice if there was an adult filter in here, yes.

     

     

  • stitlownstitlown Posts: 276

    Thanks, Catherine. I think I've established that a geograft on a geograft doesn't work. I've not dived into the underlying .duf, but the in-app behaviour is that only one set of graft-faces and hide-faces is kept and putting in the 2nd one (or the attachment to the attachment in my case) simply rewrites different data, thus losing the original attachment data. Maybe not that surprising, but it was worth the exploration.

    My challenge is still to actually modify the original model, rather than create bridges, so I'm back to my non-hex modeller.  The transfer utility in DAZ does some good but the first attempt didn't pick up about 50 morphs so I'm trying a different approach now.

    Cheers.

  • Correct, a geograft directly to another geograft doesn't work. The more I think on it, there was likely a third item to act as a seam cover in that other project I worked on years back.

     

  • stitlownstitlown Posts: 276

    Just to close a loop here, there is a HEX "dissolve" command.  It sits under the edit menu and it can be used to merge surfaces (by dissolving an edge) and to remove redundant vertices AND it doesn't disrupt the UVs.  So that is half of the functionality I was looking for in HEX.  The "free tesselation" tool under the vertex modelling can be used to slice surfaces by adding new edges and the new vertices to support them, also without disrupting the UVs, and that is the other half of the functionality I was looking for.  So good news re doing these sorts of tweaks via HEX.

  • Yes, there is the ability to add by sliding over from the root line, new tessellation lines but keep a good eye on the uv set. IncreSave often. Every now and then the uv set can go wonky. Sometimes it's an easy fix, sometimes not so much.

  • stitlownstitlown Posts: 276

    Great tip - thanks.  I usually remember to save just after it all goes pffffffuuuuuttt.

  • After awhile one may develop something of an instinct or expectation that a crash is imminent. Save or incre Save.

    I've also developed the habit of everytime as I'm working, when I say 'okay' [meaning okay that worked], SAVE or incre Save.

    And if for any reason one is working on a massive project, save out an .obj now and then too. And also [because it ever only happened once but still it happened] after a number of incre saves have been made, start another saving folder - can be nested so it's an easy find. [one time Hexagon not only destroyed the project file I was working on, but somehow managed to also destroy everything in that folder, n.b. I've been using Hexagon for years now, and this only happened once]

     

  • stitlownstitlown Posts: 276

    :). Thanks

  • mindsongmindsong Posts: 1,693

    I'm probably not understanding the problem, but did recall a thread from way back where varsel joined two objs preserving the UVs by naming them the same and exporting them - about halfway down the thread below (and you responded back then, so I'm guessing it's not what you're looking for in this case. Useful all the same to others passing by):

      https://www.daz3d.com/forums/discussion/40153/combining-two-objects

    hope this helps (someone?).

    I was actually looking for a similar function and recall that by exporting two objects in some hexagon-way, that it would even weld duplicate vertices and save the UVs. Gotta find that. Saved it at the time, knowing I'd need it, and ... gone with the ether so far.

    best,

    --ms

     

  • stitlownstitlown Posts: 276

    Hi, Mindsong. Yep, apparently exporting .obj from Hex where multile hex nodes have the same name will create one .obj mesh of the combined hex nodes. The export options include a number of items as to what is / isn't exported and what is done with eg duplicates. Per the screenshot. Export is in the menus File/export/wavefront obj .... then show where the file will go and the export dialogue opens.

    While we're documenting useful / interesting stuff, One of my big frustrations in these minor model tweaks is that somewhere the vertex orders get changed, and when that happens importing morph files becomes a nonsense as completely rabid morphs ensue and completely rabid UV mappings ensue. It appears DAZ, Hex and my chosen modelling program AC3D all preserve the existing vertex order (as known to each one - eg if you add a vertex somewhere, a new order ensues) and I've not (yet) found a program that will re-order vertices to a consistent order. Blender has some re-order vertex options but it's sort of one-dimensional in that you can re-order (amongst several options including "random" - why????) in viewport x-order or y-order, and that may clear up many mis-orderings, but it won't clear up all.

    In the end (after literally days fart-arseing around getting nowhere), I went back to the three same-model-different-UVs I started with and re-edited them in AC3D taking great care that I did all the edits in exactly the same order, and that got me three new tweaked-shape meshes that had identical orders and could now be used to load my different UV maps.  I tried doing the "great care" editing in Hex, Hut in hex, the moment you hit undo, hex removes all material associations, which, for my model, was a whole bunch of time to re-associate, if I went that route, hence the reversion to AC3D which is less feral.

    Screenshot (498).png
    748 x 600 - 110K
  • On the other hand, knowing that Hexagon willingly zaps all the surfaces - one can use surfaces to assist in the creation process and/or in morphing situations {surfaces matter not for this on export}, so I tend to consider surfaces as temporary until one is actually polishing up the final work.

    After using Edit > undo {or any function that might zap the surfaces such as merging dots} always click on what might still appear to be existing surfaces to force that panel to refresh. IF one continues working trying to use non-existent surfaces one will crash Hexagon.

  • mindsongmindsong Posts: 1,693

    stitlown said:

    Hi, Mindsong. Yep, apparently exporting .obj from Hex where multile hex nodes have the same name will create one .obj mesh of the combined hex nodes. The export options include a number of items as to what is / isn't exported and what is done with eg duplicates. Per the screenshot. Export is in the menus File/export/wavefront obj .... then show where the file will go and the export dialogue opens.

    ...

    tnx for the reply,

    What I recall, and I have a vague memory that it was user @JOdel that posted it (way back, could be wrong), that when using one, or a mix of hex 'features', that the holy grail of merging, vertex-order preservation when export-auto-welding, and UV preservation at the end of it all was somehow possible with the right sequence of user-steps... heh. I may just take an evening and scroll back and find that bugger, and see if it's actually there and what I thought it was, as it was a eureka moment when I first saw it.

    I think the thing a bunch of us were trying to do back then (when geografts were new and odd), was to see if we could permanently merge geografts and their bones/morphs onto the target figures, while preserving the UVs of both. I dunno if anyone ever figured out the workflow for doing the merge in hex and preserving/re-applying/integrating the geograft bones/morphs into/onto the target figure. Useful for add-on tails, gens, tongues, etc. At the time I think a bunch of us wanted a *complete* Genesis1 human figure that had all the 'parts' present and working as expected without having to deal with the geograft stuff - especially when migrating figures in and out of DS via CR2/FBX/... I think the diffeomorphic/blender stuff has mostly managed this for blender exports, but a DAZ-to-fbx equiv would still be a great capability.

    This was back in the G1 release era, so it's been a while, but I think the value of the capability is still useful. (Maybe the seasoned vets know the trick as second-nature, while us dabblers keep (re)learning the silly technique every few years... lol)

    best,

    --ms

  • mindsongmindsong Posts: 1,693

    Catherine3678ab said:

    On the other hand, knowing that Hexagon willingly zaps all the surfaces - one can use surfaces to assist in the creation process and/or in morphing situations {surfaces matter not for this on export}, so I tend to consider surfaces as temporary until one is actually polishing up the final work.

    After using Edit > undo {or any function that might zap the surfaces such as merging dots} always click on what might still appear to be existing surfaces to force that panel to refresh. IF one continues working trying to use non-existent surfaces one will crash Hexagon.

    maybe *that's* the association I've never made (on crashes), that *seems* random until you notice it... good one to know of, tnx!

    --ms

  • stitlownstitlown Posts: 276

    Thanks, guys. All interesting tips and tricks.

  • stitlownstitlown Posts: 276

    A small valuable thing to add in here re Hex. Hex eports .obj files with the vertices sorted in a specific order. I've not studied it fully, but the first criterion is ascending x-value.  This is useful for when you need to get multiple .obj files into the same vertex order (eg for DAZ UV files).

    Another thing to note is that Hex seems to export ,obj files (on my settings and I've not found an alternative that works) at 10% of the scale at which eg they came across from DAZ on the HexBridge.  Quirky but not an issue. Just import the file into DAZ at 1000% and all is good.  Why not HexBridge back to DAZ you ask? Because the critical step is resorting the vertex order an all that follows from that, hence the need to export to .obj.

  • AscaniaAscania Posts: 1,838

    The above statement is misleading.

    Both, Hexagon and DAZ|Studio work at the same scale. An object created in Hexagon and exported at 100% will, when imported at 100% to DAZ|Studio be exactly the same size. Objects exported from DAZ|Studio at 100% will be the same sizen in Hexagon when imported at 100%.

    The exception to that is the Bridge. Objects imported into Hexagon from DAZ|Studio over the HexBridge will NOT conform to the standard scale. For the least amount of hassle, any objects brought into Hexagon over the bridge should also leave over the bridge as the bridge takes care of adjusting the scaling.

  • Saxa -- SDSaxa -- SD Posts: 871

    stitlown said:

    Why not HexBridge back to DAZ you ask? Because the critical step is resorting the vertex order an all that follows from that, hence the need to export to .obj.

    Would be curious to know what you are doing that vert order changes when using DS-Hex Bridge.

    Have made umpteen morphs of all kinds of scales and zero issue when back in DAZ.

    The objs did make, like Ascania says, the scale was 100% identical.

  • The only time I'm aware of in which D/S will make real changes to a mesh is when the mesh has n-gons. D/S will "fix" such mesh - and not in a way most of us would want. Solution is to make models with no n-gons. In Hexagon there is a tool utility to triangulate them.

  • Saxa -- SDSaxa -- SD Posts: 871
    edited April 2023

    2nd time, actually slowed down to read op's subject-line.

    Merged surfaces and culled and added some quads via tesselate too for one project.  Never checked exported obj, but would imagine vert order changed cos I made changes.  It being a new object never even considered bridge.  Still obj export was still all at 100%.

     

    Had ngons in other projects.  Nice to hear Hex has a fix for that too.  Any tris though - end up deleting and making as quads. Still essential that program can deal with those ngons even making tris.

    Post edited by Saxa -- SD on
  • Well when Hexagon makes tris, I delete that mesh and put in quads wherever possible.

  • Saxa -- SDSaxa -- SD Posts: 871

    Yeah those tris don't sync well with DS in my experiments.  Seems DS is built for quads.

  • stitlownstitlown Posts: 276
    edited April 2023

    Ascania said:

    The exception to that is the Bridge. Objects imported into Hexagon from DAZ|Studio over the HexBridge will NOT conform to the standard scale. For the least amount of hassle, any objects brought into Hexagon over the bridge should also leave over the bridge as the bridge takes care of adjusting the scaling.

    Thanks Asciana. It's the Bridge I'm using hence gettting the scale issues. I'm not going back over the Bridge, for this purpose, because I need Hex to re-sort the vertex order for me.

    Post edited by stitlown on
  • stitlownstitlown Posts: 276
    edited April 2023

    Saxa -- SD said:

    stitlown said:

    Why not HexBridge back to DAZ you ask? Because the critical step is resorting the vertex order an all that follows from that, hence the need to export to .obj.

    Would be curious to know what you are doing that vert order changes when using DS-Hex Bridge.

    Clearly didn't explain myself / my issue well enough. Like you, I have no problem back and forth across the Bridge on one model. But here I was tweaking one model into a 2nd, 3rd and 4th slight variation of the model and in the tweaking (eg adding vertices and edges) vertex order gets changed. Then to try and regain some order across the models I needed to get them into some sort of broadly consistent vertex order, hence stepping outside the Bridge.

    Post edited by stitlown on
  • Saxa -- SDSaxa -- SD Posts: 871

    Thank for explanantion.

    My bad for just dropping in and skimming the most recent posts, where scale was an issue. 

    For whatever its worth, if i know i'm gonna add verts, then i export as OBJ from DS, and scale back and forth to Hex was always good.  The issue of new UVing was unfortunately unavoidable and then deal with new OBJ in DS.

    Am unsure how even if getting vert order identical would address the issue you have new number of verts which auto-trigger previous morphs null and void.

     

  • stitlownstitlown Posts: 276

    Saxa -- SD said:

    Am unsure how even if getting vert order identical would address the issue you have new number of verts which auto-trigger previous morphs null and void.

    The Transfer Utility is actually a very versatile and effective tool that does a very good first-order job of transferring morphs (and bones and weightmaps and most surface definitions) from one model to a broadly similar model. It appears to work on similarilty of vertex position - so ... if one model is displaced relative to another, it pays to have an interim model that is not displaced, run the transfer utility on that and then update that interim model with a new base geometry in the "displaced" position. Because morphs are deltas from a base location, they remain valid relative to the new base geometry. Frustratingly (given it's a slow job for a human but would be a fast job for a machine - and I've raised a feature request re this with DAZ), transfer utility does not replicate morph limits nor any erc-freeze outcomes (eg bone translations, scales, rotations) which all have to be manually recreated.

    The one trick to using the Transfer Utility for morphs is the morphs have to be turned on (ie non-zero). So you set all of the morphs on the source figure on at once (which can give some crazy shapes, but no matter) then run Transfer Utility fitting the target figure to the Source figure.  When the figure is unparented / unfitted-to, it's shape is restored and the morphs are ready for tweaking (tweaking because the transfer is good, but not perfect).

  • FirstBastionFirstBastion Posts: 7,317
    edited April 2023

    I have never used the bridge, but is you import and export manually,  exporting anything from DS at 100% imports into Hexagon at the same 100% size, and then exporting from hexagon at 100% will import back into DS at 100%.  They have the exact same scale.

     

     

    Poser on the otherhand,   is a whole different story.

    Post edited by FirstBastion on
Sign In or Register to comment.