 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It seems that the merge{} structure doesn't elliminate internal surfaces as
it should; see this scene:
camera {
location -10*z
look_at z
}
merge {
sphere {x,2}
sphere {-x,2}
pigment {rgbt .9}
finish {ambient 1}
}
Manually constructing the merge doesn't work either:
intersection {
sphere {x,2 inverse}
sphere {-x,2 inverse}
pigment {rgbt .9}
finish {ambient 1}
inverse
}
Although if you remove the final 'inverse,' you do get the inverse of the
result you want.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> It seems that the merge{} structure doesn't elliminate internal surfaces as
> it should; see this scene:
Indeed, it looks like inner intersections are not properly eliminated
somewhere. We are working to fix this in the next beta (if possible).
> Manually constructing the merge doesn't work either:
This is not surprising because internally both your "manual" and your
"automatic" approach produce the exact same result. That is, and "inverse"
of CSG operation (depending on type) is equal directly specifying the other
CSG operation.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Manually constructing the merge doesn't work either:
>
> This is not surprising because internally both your "manual" and your
> "automatic" approach produce the exact same result.
Yeah... the last time I looked at the source code I thought I saw some
merge-specific code in there, so I figured there might be some optimization
going on and they weren't exactly the same internally.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> Yeah... the last time I looked at the source code I thought I saw some
> merge-specific code in there, so I figured there might be some optimization
> going on and they weren't exactly the same internally.
Well,one thing that was noticed while cleaning up plenty of CSG code (it was
very obfuscated) was that many "optimisations" were just workaround that
worked around workarounds of things that were actual design deficiencies.
So all those were cleaned out, which resulted in several new bugs (which was
not unexpected) and also exposed some other design problems the in the way
CSG objects are created and implemented.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> was that many "optimisations" were just workaround that
> worked around workarounds of things that were actual design deficiencies.
Haha =)
All this changing of the source code seems like a pretty big step towards
4.0. I'm wondering if it was intended that way, or if all this work will
still be scrapped in favor of changing the license later on? Has anything
been moved to C++ yet?
I'm just curious. If you don't want to release this information to the
"public" yet, that's fine.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> or if all this work will
> still be scrapped in favor of changing the license later on?
In order to change the license a lot of code will have to be scrapped, but a
lot of code has already been scrapped.
> Has anything been moved to C++ yet?
That process started with POV-Ray 3.5 already.
> I'm just curious. If you don't want to release this information to the
> "public" yet, that's fine.
Not more than I said, and I would urge everyone to not jump to any
conclusions or drill further on the subject. As usual, once the final
release is done, the code will be released (shortly after the binaries).
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> It seems that the merge{} structure doesn't elliminate internal surfaces as
> it should; see this scene:
fixed, thanks.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
