Hi Don,
welcome to the OpenSG Users list! :) Ladies and gentlemen: Don Burns,
one of the lead developers of OpenSceneGraph.
Don Burns wrote:
> Hi Allen,
>
> I appreciate your comments and forwarding my post from osg-users. It is
> evident from my comments and from Dirk's that there is significant
> ignorance about each other's work.
That is certainly true. While I've briefly looked at your codebase, I'm
definitely not an expert on the details.
>(Dirk wrote in respons to your comment:
>
> > It also sounds like they have
> > multi-processor rendering
> I'm not sure where you got that from, especially in light of Don's
> answer to my mt-safety post.
>
> OSG has multi-processor support through Producer for years )
Absolutely, and we all know that. My comment was about Allen's comment
on the 1.2 release, which didn't seem to have anything new in that respect.
> It would seem that OpenSG's multi-threading approach attempts to address
> some of the significant problems with multibufferring.
That was one of our main goals, yes.
> If I were to take offense, it would only be to the act of posting to a
> "competitive" list to recruit users over the use of your own software.
> The rest of my post attempted to address the misconception that somehow
> osg was missing something because it was not entirely thread-safe.
That's why I kept it to one line, and only in response to a very direct
question about exactly the situation OpenSG was designed to solve.
So far we've kept our competitiveness friendly and our relationship very
civil, and I would like to keep it that way. I tried to keep this as
low-key as I could, and I didn't expect any response from your side, as
Robert and I have argued about the right level of thread-safety multiple
times over the years and we've to agree to disagree.
Now your post says some things about OpenSG that are misleading or not
quite true, and we're in a bit of a bind. My plan is to write some
longer description about what we do and how it differs from other
solutions on our Wiki, post a link to that to both lists (as I'm sure
some of our users don't know the difference either) and hopefully we can
close this chapter. I'm too busy to do that today, so it won't be up
before Monday.
> The subject of "thread safety" is a broad one and presents a lot of
> challenges. Many of the problems we saw in Performer are addressed both
> by OpenSG and OSG, but in different manners, it would seem. In fact,
> OpenSG's approach is not necessarily thread safe, either, it simply uses
> the concept of buffers (aspects?) to protect the user from changing a
> scene graph that is being used to cull/render. To truly make it thread
> safe, by protecting access to data with mutexes, etc, would have the
> same performance impact we implied on the osg-users list.
Actually that's a commonly misunderstood thing, OpenSG tries to avoid
mutexes like the plague (I've seen "lock" at the top of too many
profiles...), and therefore does give you thread-safety with minimal
locking. My description will have more details...
> I'm certainly open to learning from one another - that is one of the
> purposes of open source. But I'm not that interested in having "we are
> better because we are thread safe and you are not" being posted to our
> list.
My complete post was: "ObPlug: OpenSG is threadsafe. Contact me for
details. ;)". I didn't say anything general, and I didn't say anything
negative about OSG, and I certainly didn't say anything that's not true.
I apologize if you felt I was trying to attack OSG.
I would never do a blanket statement that OpenSG is better than OSG,
just like you would never the other way around, right? But if somebody
on the OpenSG list asks whether to use OpenSG for a project that needs
paged terrain, I do not hesitate to point people at OSG, because that's
one of the things it's much better for, and I wouldn't mind you pointing
that out, as long as it is kept as low key as mine (one line every
couple years is acceptable ;). The same logic applies to this situation,
where the user was asking for more thread-safety than OSG is designed
for and interested in providing, and was hitting the OpenSG design right
on the head.
Let's not blow this out of proportion, please. People that have invested
in a codebase based on either OpenSG or OSG will not just switch
willy-nilly. They need to have a very compelling reason and a serious
problem to do that, so a minor finger pointing our way in your flood of
mail will not make much of a difference.
Have a nice weekend
Dirk
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users