Subdividing booleans...

[Dimitri]

Below I put an image about the three possible ways a boolean object can be subdivided and the results that appear after its subdivision. The upper two images are illustrating the results of a case of plain boolean object subdivision while the other two ones are about a case of bevelled boolean object subdivision.

As it is evident the middle object gives the best results, so it would be best to focus at what can be done to have ways of producing such a mesh kind on booleans. The already existent 'connect' tool is a great aid in building such mesh kinds but it has a deficiency: it has no axis constraints. And, so, it is very difficult to produce straight lined, consistent mesh structures with it.

So, what about thinking seriously for an implementation of some axis constraints to the 'connect' tool?

[puzzledpaul]

<< So, what about thinking seriously for an implementation of some axis constraints to the 'connect' tool >>

Indeed ... couldn't agree more ... and I must've suggested this just a few times over the yrs, starting from just after (or maybe even during) the time Dan was writing Tools | Connect - probably over 8yrs ago(iirc)

I've also suggested that the ability to cut across gaps (of the same object), together with an angle readout (if full constraints were too difficult) of the destination point, compared with the start point - would be useful.

The latter would allow user to drag destination point,whilst eyeballing top left info readout ... until there was zero angle between same.

It'd not be as precise as full constraints - but it would (imo) add functionality.

I more recently re-iterated such ideas - as extensions to existing tools - during the time gga was writing 'new', supposedly better tools ... eg Extend loop and Plane loop by elements.

Since the 'new' tools were considered to be the next thing since sliced ... uno what ... I stopped banging my head against a brick wall ...

Btw - extend loop was *fatally* flawed, inso much that it didn't extend the existing loop - it formed a 'new' one based on the old ... and if the old wasn't co-planar then user ended up with a right mess.

Plane cut by elements does no more than Native Plane cut ... yes, the latter has an an extra step ...being able to re-locate plane thro a point of user's choice ... but I'd suggest that's a price worth paying.

If, rather than spending time on the above, Tools Connect had been improved - it would've been a far better use of time.



So, when I read stuff like this, copied below I was sorely tempted to comment at the time - but I didn't.

Added to the more recent comments about being 'unforgiving' - just because I consider rigorous testing to be in wings' best long -term interests ... it really does make me wonder why I bother.

(I've also given my thoughts re how to approach re-topo, too ...)

Whilst I don't share quite the same love affair with booleans as others in our midst, I do see (and acknowledge) their use and importance to others that wish to employ them in their workflow.

I'd suggest that tidying up the issues associated with their use should be a a higher priority task than it seems to be ... from where I stand, anyway.

I suspect more users would enjoy using said features than other - Ahhhh ...somewhat more obscure ones ...

pp


<< Paul, I do not have any objection for an approach that keeps always in mind an integration with the already existent tools. The issue is, however, that if we have to wait for such a thing, Wings will stay without any progress maybe for years or it will be abandoned altogetherly and seen just as a relic from the past, proper for a museum exhibition, having to do with the history of 3D modelling apps. : - )

So, instead of criticizing my propositions why not proposing some new tools in line with your own approach? I would be very happy to see some such propositions. Let begin sharing some ideas about retopo tools in Wings, for example.

My propositions may not be so perfect but at least they are an effort to continue the development of this so nice app about which we are discussing in the present forum >>

[Dimitri]

Paul, I have never been against implementing constraints to the 'connect' tool. I just wanted some more efficient solutions for being able to work in a more smooth and fast way.

Creating new objects (mainly by using 'shell extrude') for having reference points to create new plane loops (or 'plane cuts') is really a burden. It frustrates the user in a quite significant degree.

I still believe that tools like 'extend loops' or 'plane loop by elements' could be extremely useful... in the case they would work properly, of course.

So, implementing constraints to 'connect' tool does not contradict, in any way, the need for the existence of all the other tools.

Btw... I have an idea for the 'plane loop by elements' that I will share soon (I need to create some visual explanations before sharing it).

[Dimitri]

Thinking about the whole thing better, it seems that even having only some ‘xy, xz, yz’ constraints for the ‘connect’ tool will be very helpful. It will give to the user the opportunity to produce whole loops very easily.

Of course, having a way to have constraints in any given direction would be the perfect solution but this should not be an impediment for not having even the simple scene axis constraints…