Greetings Paul!
Yea, I came to the same conclusion also! That is why I went to the second
choice.
Oh! I goofed when I gave you that last corrected code segment. It should be:"
Code:
colors->push_back(osg::Vec4(_PrimaryColor.r(), _PrimaryColor.g(),
_PrimaryColor.b(), 1.0 - getTransparency())
On 9/29/2011 4:44 PM, David Glenn wrote:
Turns out that what you did worked but if you looked at the object that I gave
you, it's solid ( its suppose to be transparent) The transparency is set at a
node that is labeled WATER that introduces the transparency to the face
(Primary) color.
Hi Da
I'm still busy with other tasks. Why don't you post an updated submission to
osg-submissions, which contains my changed plus what you added to handle
transparency? Then Robert can fold it in, and I can test with your complete file
when I finally get some time to take a look.
-Paul
On 10/6/
Greetings Paul!
I tested the second method just about every way I can think of and it meets our
requirements, so I'm going with it unless you can come up with a better answer
(I can always change it). So check it when you have the time.
Thanks!
David.
David Glenn
--
I agree, your model has blending enabled, and the face has non-1.0 transparency.
It'll be a couple days before I can dig into this. When I fixed the rgb part of
this issue, I looked through the flt spec, and don't remember seeing anything
about how transparency should be handled. But I'll take
Greetings Paul:
I thought I was going to get a break, but I guess that there is no rest for the
weary. Good news is that I have this guy that on-board that's on top of that.
Turns out that what you did worked but if you looked at the object that I gave
you, it's solid ( its suppose to be trans
Greetings Paul:
Managed to test your patch on OSG 2.8.1 and OSG 3.0.1 before I called it the
week and on both it works fine!
Thanks! Good Job Paul!
...
David Glenn - D Glenn Computer Graphics & Media Systems.
D Glenn (a.k.a David Glenn) - Moving Heaven and Earth!
-
Hi all -- David and I have been discussing this offline, and we've arrived at a
fix that will be posted shortly.
Turns out the actual issue was that the vertex record flags field had the
NO_COLOR bit set, but the OSG flt loader wasn't checking for that bit. If
NO_COLOR is set, the color index
Paul Martz wrote:
> On 9/27/2011 10:55 AM, David Glenn wrote:
>
> > Greetings All:
> >
> > Something I found that is interesting in Creator 3.4 (Open Flight) that is
> > not reflected in OSG.
> >
> > In Creator Face Attributes, under the Drawing tab, If your set the Shade to
> > Gouraud, you
On 9/27/2011 10:55 AM, David Glenn wrote:
Greetings All:
Something I found that is interesting in Creator 3.4 (Open Flight) that is not
reflected in OSG.
In Creator Face Attributes, under the Drawing tab, If your set the Shade to
Gouraud, you are shading at the vector level, hence you usually
Greetings All:
Something I found that is interesting in Creator 3.4 (Open Flight) that is not
reflected in OSG.
In Creator Face Attributes, under the Drawing tab, If your set the Shade to
Gouraud, you are shading at the vector level, hence you usually set the colors
at the vector points. What
11 matches
Mail list logo