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.

Here is a test render of the sink. I needed to test the metals I wanted and the effects of a mirror.
Too much gold so far. (60) passes of MLT mode.

Dali's bathrooms elements !)

> Dali's bathrooms elements !)

And with Flow and Twist I can now make a melting clock to put over the side of the sink!!!

There's a Salvador Dalí museum just a few hours drive away in St. Pete Florida... It's on my "to-visit" list.

http://thedali.org/