MagicMike,

I was always trying to make "scrolls" as solid and failed. This morning, following your example and forgetting about solid, which I wont need anyway afterwards, I finally managed to create one that I like as a joint surface. I think Michael said something about adjacent surfaces that are self-intersecting or pretty close can causes booleans to fail.

The main reasons I prefer to work with solid are: yes it's easier to select and edit as a single object, though a joint surface is also a single object and I'm sure a solid is leak tight, no gap and no fliped normals. For some type of work like say 3D printing, I believe it's necessary to have leak tight objects but I'm sure for many other type of work, tiny gap may pretty well be insignificant.

I was also thinking about adding SubD effect (outside of Moi of course) like say a small amount of mesh displacement to simulate chisel marks or whatever especially for things like leafs and floral motifs. Now that I've found an add-on that will make retopology much easier, for me at least, I can see myself doing much more then just adding a little displacement modifier. But but but, Moi Moi Moi, I just love it and I want to use it as much as possible before going out, ideally, only for rendering. So, if joint surfaces make my life easier, why not.

Again Mike, the work you do is just great, keep them coming.

Thanks,
Felix

<<< and sports an illegal 15 liters per flush!
yes but you can put inside some little bricks inside for come back in the legacy :D

Hi Michael,

You can tell that I was introduced to 3D design through SketchUp. ;-)
I see what you mean. I'm tending to gear surface creation towards rendering, which looks at things superficially.

It's just a fun to create the whole shape of objects and the inner-workings of a model, and there are times when that's the goal of a design, but there's usually a cost with memory and manipulation speed associated.
I also run into problems when trying to give thickness to surfaces to make thin-walled elements. The same type of problems associated with fillet where sharp angles, space constraints and funny edges can trip up the Shell and Offset commands.

I'm hoping the normals issue is what gives me odd-colored or odd-reflective objects in my Kerkythea renderings. Must be either that or some type of object duplication, as it will produce the same error in different rendering modes.
MoI cannot currently show the direction of the normals, but if I could find the switch in Kerkythea that enables both sides, that would not be an issue. I see where you can choose both sides in the emission parameter but I have the feeling that Kerhythea enables both sides to start with.
...challenge.

On the note of surface matching: ;-)
So! Do you think we may see a slightly enhanced Blend tool someday?
One that will blend across the edges containing multiple curve segments and even intersections?
One that will blend between not only two, but 3 or 4 individual edges with options for tangent types on each edge?
Sorry, thought I'd plug that one again. Seems to be something I end up wishing for at some point in every model.

Thanks for the good explanation on solids and open surfaces!

Pilou... if what makes the brick are legal, then yes. ;-)
I hate these new toilets that use less water. The just never flush right.
Here in north Florida we are sitting on an aquifer with 3000 tera-liters of an endless supply of water. Sure it makes sense for most of the country that gets their water from reservoirs, but here, conserving water is like making soup to stretch a piece of meat while dining at an all-you-can-eat buffet.

Felix... I get what you were talking about. I'll often make both solid and open surfaces without regard to which is which.
But I imagine if you make the open surface, you can Flow it easier - then when you are done with distortions you can find ways to make the remaining object a solid but constructing final surfaces. Not an easy task sometimes.

Thanks Michael for your explanation.

I still don't understand why some combination of solids wont union, event worst, in some cases it goes bazurk, I know you need a file and here it is.

It's just a test I did trying to find something that wont union and I got even better, union went bazurk on me. Basically, I created a sphere and used a plain circle to create a ring of sphere that union without problem. Then I copied the first ring and I put a few on the outside of the first ring almost randomly. I tried to union all 6 rings together and voila! A joint surface was created and a bunch of unjoined surfaces where created as well but I tried to join this result and it worked, creating a single object but you'll see as well that some shere have lost some part of there skin sort of speak.

Since it's not the first time I obtain a similar result, I'd like to know if there a way to at least get a correct joined surface, by this I mean without lost of some part of the original surface. Though I think I could create a good joined surface in this particular case I would appreciate this a lot since I would use this method to create the central part of flowers with a few hundred tiny sphere disposed in spiral on the surface of a dome for example, sorry I don't know the name in english.

Thanks,
Felix

Hi Mike,

> I'm hoping the normals issue is what gives me odd-colored
> or odd-reflective objects in my Kerkythea renderings.

Maybe, but it doesn't really sound like it...

Can you maybe prepare an example file that has just the one problem object in it so I could take a look and try to give you a suggestion?


> So! Do you think we may see a slightly enhanced Blend tool someday?

Yup, I want to do an overhaul of surface blend at some point here in v3, specifically to allow a longer chain of edges on either side of the blend instead of only 1-to-1 like it does currently.

- Michael

Hi Felix - so that boolean problem looks like a bug, something is getting mangled in the calculation of the intersection curves between the pieces. I'll put it on my list to investigate.

But it also looks like a contributing factor is the relatively small size of the objects - smaller sized objects can tend to make the booleans job harder - I'd suggest building your objects to be around a factor of 10 larger in size instead of so small.

For example here I've attached a version of your file and all I did was scale it up by a factor of 10 times in size and move them closer to the origin and it seems to boolean together ok now.

It can tend to confuse the booleans when you have small features which start to approach the 0.001 fitting tolerance, it will try to do things like combine intersections together that are within that distance of each other and that can sometimes have a tendency to disrupt the boolean process, something like trim loops get portions of them collapsed down and make an invalid loop.

In your original file there you've got spheres that have a radius of 0.06 inches - basically try to avoid making individual features which are small enough that they're measured in hundredths, try building things at more around 10 times larger than that at a minimum and you'll probably avoid a lot of problems.

- Michael

GREAT SCOTT, MICHAEL! - I think I figured it out!

I created this render scene with three versions of the lid and the tank of the toilet model.
The upright one is the original and the first prone one (left on bottom) is a copy of the upright one.
The lid object at the top of the one on the right has had the normals reversed with the non-UI "Flip" command.
A single porcelain type material was applied to everything.

As you can see from these pics, If I'm not mistaken (the last image has a darker gamma applied): the lid object on the top of the right prone model is the same color as the rest of the tank model.
The original lid objects are not only discolored, but have a different reflection quality.




Michael, I think you may know right off, but just in case, I provided a .3dm and .obj file inside "objects_normals_test_01.zip".

Okay, it seems obvious. With Kerkythea, normal orientation counts.
So I have to find one of two solutions. Either 1) I have to find out how to get Kerkythea to see each side as the same front side and apply the materials likewise,
or 2) I would like to ask you to consider a non-UI command for a future release that could show a special color to the back-side of the surface to indicate it's normal orientation.
It would probably have to be done on the direct-x level, but would give users a special-case way to see which objects need to have the "Flip" command applied.


Oh, and now you have me anxious for the future enhancement of the Blend tool. =-)

Thanks.

TARNATIONS! I dug fer gold and got silver!



You can see Kerky give my backside a woopin!
Other than exporting an .obj, importing it to Kerky, then running one material to test for reverse normals... there's no way to tell in MoI, no?

One good place to put an indicator could be the mesh exporter dialog in MoI. When you go to make your meshes, maybe ones with a different outline color could represent the backsides...


Well, at least I know now what to look for.

Hi Mike, hmm that seems a bit unusual that backfacing or not would alter the reflectivity in that way - I wonder if that's actually a bug in Kerkythea.


> 2) I would like to ask you to consider a non-UI command
> for a future release that could show a special color to the
> back-side of the surface to indicate it's normal orientation.

Yup, this is something that I already have wanted to do, it's just like everything else, hard to find the time to do it with also a lot of other things on the list as well...

I haven't quite figured out if it should be just built in to the export process or whether it could be part of some group of analysis commands or what quite yet.

- Michael

Hi Mike,

> Other than exporting an .obj, importing it to Kerky, then
> running one material to test for reverse normals... there's
> no way to tell in MoI, no?

Well, if you make solids then they'll be pointing towards the outside of the solid.

But yeah there's not really much in MoI that is sensitive to the normal direction, I've taken some pains not to make very much stuff dependent on it. About the only thing I can think of is if you do a surface offset it will go along the positive normal direction as long as the Flip checkbox inside that command is not turned on.

- Michael

Thanks, Michael.

True... that sounds like a good thing to try.

HaHa!

Michael, I guess there is a limit that I keep crossing as I try to create things that are quite small and it seems to be a pretty good reason why bools fail on me so often. Could this relatively large limit of 0.001 unit come from the origin of the code in the library? In the 70s 8 bit processor was the norm but today even a 32 bit app should be able to go way behond this.

I'll try not to forget this in the future.

I just tried to scale up a couple of parts I had trouble to union before and it still fail but in this case it didn't go crazy on me. In this particular case though, the reason I wanted to union those parts was more to have a single object to work with. At this time, I know I could simply give those parts the same name (or style) and select them from the browser instead but that would be not only ackward but counter intuitive. Basically, it's all the parts for a door, the door frame individual parts, the panels, etc. It would be nice to kind of group all those items into an assembled door and work with this "door" as a single object while still have access to individual parts of the door with there own individual name. I think you mentioned that you wanted to work on something like that in the future, can we hope for this in V3?

Sorry Mike for the digression.

Thanks,
Felix

Hi Felix,

> Could this relatively large limit of 0.001 unit come from
> the origin of the code in the library?

Not really - I mean 1/1000th of a unit is what I'd consider pretty small, I have a hard time viewing that as "relatively large" myself...

Various different processes need to carry out their calculations until they reach a particular accuracy level which they can then judge to be good enough. If that accuracy level is set to be too high, then those processes will both take a lot of extra time and also generate much more dense results for things like intersection curve results, etc...

I am generally moving things towards a system that uses a relative fraction of the object's bounding size rather than a fixed tolerance size though. But that can still be problematic when you've got just some little tiny portion of the object being a small size.


> In the 70s 8 bit processor was the norm but today even a
> 32 bit app should be able to go way behond this.

Not really - I mean with a simple object it would be possible but it would not work well to say make everything 20 times larger in data size, it would especially really cause a problem with models that are already of a high complexity as it is.


If you're unioning a whole lot of things together in one pass you may also get some better results by only selecting 2 pieces at a time - sometimes union can have some additional difficulty if you've selected some large number of separate pieces and it happens to process some pairs that do not actually touch each other first. It will try to sort things so that if you have one large object and a bunch of small ones touching it, that it will do the large one first so they'll all be intersecting but if you have a whole lot of daisy-chained type same size pieces you may need to select them 2 at time, at least that's worth a try if you run into a problem.


> It would be nice to kind of group all those items into an
> assembled door and work with this "door" as a single object
> while still have access to individual parts of the door with
> there own individual name. I think you mentioned that you
> wanted to work on something like that in the future, can we
> hope for this in V3?

Yup, that is something that I want to work on in v3 - basically a group mechanism will be a way to have a hierarchy of names that you'll be able to expand and collapse.

- Michael

Michael,

what I mean by relatively large is this 1 x 10-3 compared with something like 4.9406564584124654 x 10−324 (Double floating-point).

But I also understand the constraint with what you added below.

->Various different processes need to carry out their calculations until they reach a particular accuracy level which they can then judge to be good enough. If that accuracy level is
-> set to be too high, then those processes will both take a lot of extra time and also generate much more dense results for things like intersection curve results, etc...


->I am generally moving things towards a system that uses a relative fraction of the object's bounding size rather than a fixed tolerance size though. But that can still be
->problematic when you've got just some little tiny portion of the object being a small size.

Maybe, just maybe it would be possible to have something like an on-demand tolerance control. I'm sure a 0.001 is "small" enough in most case but as you well know there are exceptions and in those cases it would be nice to have a say in specific situations but not overal say like the mesh angle parameter work. For example, we know with the ring file I provided, scaling things up made union work, I even scaled it back 1/10 and it was fine, then I suppose that lowering the tolerance could also work in this particular case. I tried this same approach on something else and it didn't work, which brings up the question of feedback, especially when a command fails to give us a result but I know this is complicated as well, maybe even more then this tolerance thing.

***
If you're unioning a whole lot of things together in one pass you may also get some better results by only selecting 2 pieces at a time - sometimes union can have some additional difficulty if you've selected some large number of separate pieces and it happens to process some pairs that do not actually touch each other first. It will try to sort things so that if you have one large object and a bunch of small ones touching it, that it will do the large one first so they'll all be intersecting but if you have a whole lot of daisy-chained type same size pieces you may need to select them 2 at time, at least that's worth a try if you run into a problem.
***

Though this approach is fine when only a few objects are in play but in practice for my flower "middle" part for example (100+ spheres), I migth as well think of a totally different approach to create them and most likely not in Moi unfortunatly.


As for the group mechanism, I'm very happy to see it will be there at some point.

Thanks,
Felix

Hi Felix,

> what I mean by relatively large is this 1 x 10-3 compared
> with something like 4.9406564584124654 x 10−324
> (Double floating-point).

Yeah, but you may have gotten a bit of a wrong idea about floating point numbers though - even though the smallest representable number will be something similar to what you're saying there that doesn't mean that you can do much with that number other than just look at it by itself. Once you start doing arithmetic between different numbers you're looking at accuracy of more like 1e-16 or something more in that range.

The smallest possible number that can be represented is not also the accuracy that arithmetic works with...

Each floating point number has a separate mantissa and exponent part to it, and when you do arithmetic between 2 numbers if their exponents are way different the one that's way smaller will sort of evaporate away.

The "floating" part is kind of like a floating range - you get precision with arithmetic between numbers that are within the same exponent range of each other, so like 3.0e-100 + 4.0e-100 will generate 7.0e-100 ok but if you try to do 1 + 3.0e-100 it will just give a result of 1 because there's a 100 digit difference between those numbers.


> Maybe, just maybe it would be possible to have something
> like an on-demand tolerance control.

I may have this eventually but it tends to open up a pandora's box of various problems when it is set wrongly and I've often seen it set badly in practice before.

See this thread for some previous discussion on it:
http://moi3d.com/forum/index.php?webtag=MOI&msg=4215.4

- Michael

Michael,

I've exagerated a bit to much on purpose just to say that 1/1000 wasn't that small.

May I suggest something like a list of tolerance choices in a limited range that are not known to cause problem except for longer calculation time.

Thanks,
Felix

Here is a test render with the toilet placed in the final architecture.
The bathroom is designed with a 12'x12' footprint and the toilet sits in a corner nook, with two slim frosted-glass windows on the one wall.

The materials are temporary for testing purposes and no details have been added to the bathroom scene besides the toilet and basic trim.
But my current purpose now is to hammer out the lighting and design challenges first.
It's been a good exercise so far.

The following pic was rendered in Kerkythea Boost with 115 passes in the mode called: "Metropolis Light Transport (BiPT)",
which takes a looong time to render, but I feel it has the best results when subtle light bounces, reflections and caustics are concerned.
This constitutes about 20 hours of render time with a four-core i7 cpu. The image was at 2000x2000 pixels, but reduced to 1000x1000.
I like to render the MLT images at twice the pixel dimensions, then reduce it when final because there is a trade-off and most of MLT's inherent noise is reduced.
More poly's and lights add exponentially to the render time of course, and there are a lot in this current incarnation of the toilet model. I'll scale down the poly count when I get more familiar with what I can get away with in this scene.

I ran an earlier "Photon Map + caustic + fine, aa 0.3", but the results were a little cartoon for me.
I'm still at the bottom of the rendering learning curve, though.

As I progress with my scene I'll produce more renders.

It's looking great Mike! The only down thing is that you can't really appreciate all that detail on the handle area when it's a bit far away and in shadow like that...

- Michael

Thanks,

Yes, the handle is kinda diminutive when rendered in a room scene.
The advantage of rendering in a real-world inspired scene space is that you can get a better "eye" on how things like inventions and custom shapes would actually "feel".
(in a manner of speaking).

I created the toilet, and bathroom to size. And by doing that I soon realized when rendering that the toiled look more "grand" when modeled by itself with dramatic lighting.
Here, it kinda just looks like a humble toilet with a cool handle.

Because the room I created is not really a large open space, the resulting renders will have to be done as separate piece shots, focusing on the highlights, like the handle.
When you think about it, most of those nice, modern living-space renders architects like to show off, if brought to reality, would have to lead you to believe that only billionaires commissioned these pieces! Where someone's "bathroom from the future" is actually larger than my whole house!

I say a real challenge is designing for spaces that real humans live in. Where most may have rooms that might not exceed 12' in any direction.