Hi,
I would like to include several attributes of openflight face records, namely
Surface Material Code, and Feature ID into the scene graph. Essentialy I am
looking at modifying the openflight plugin and the ive plugin to read/write
these attributes.
I want to use this information as a cost
Hi,
I must have been staying too long in front of my computer lately...
The following code works fine:
Code:
// GLSL
out vec4 out_color;
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
out_color = gl_Color;
}
// Trivial fragment shader code omitted
Hi All,
I have been investigating issues with handling of .dds image files
that contain DXT1 compressed RGB data, with some of these files being
picked out as being RGBA because they have a black pixel within them.
I've looked at what documentation on DXT1 I can find on the web and
have what
Hi All,
I have now implemented the various options I suggested in my previous
post, and for now have opted to default to DXT1 RGB pixle format for
DXT1 files, unless the alpha bit in the dds header is set, then it
will choose DXT1 RGBA pixel format. The OSG's DDS plugin does set the
alpha bit
Hi Robert,
I hope I do not spread misinformation, as I am not fully sure nor I know
exact details but I believe that logic for finding if DXT1 pixels are
transparent, should first check the order of entries in chunk( 4x4pixels)
micropallete. And if its ascending then chunk may not contain
To Sukender: thank you for your concern, but indeed your file has been removed,
at least for me, this is the message displayed at the thread you provided where
I guess the file was: The Extension '7z' was deactivated by an board admin,
therefore this Attachment is not displayed.
For the
Hi Wojtek,
On Thu, Apr 14, 2011 at 12:23 PM, Wojciech Lewandowski
lewandow...@ai.com.pl wrote:
I hope I do not spread misinformation, as I am not fully sure nor I know
exact details but I believe that logic for finding if DXT1 pixels are
transparent, should first check the order of entries in
14.04.2011 16:16, Robert Osfield wrote:
The heart of the problem is that the DDS file format doesn't
distiguish between the
two varients of DXT1, there is an alpha bit in the DDS header that
could be used,
but 3rd party tools like nvdxt and nvcompress that write DDS files
don't set this bit
so
14.04.2011 16:34, Mikhail I. Izmestev wrote:
14.04.2011 16:16, Robert Osfield wrote:
The heart of the problem is that the DDS file format doesn't
distiguish between the
two varients of DXT1, there is an alpha bit in the DDS header that
could be used,
but 3rd party tools like nvdxt and
14.04.2011 16:43, Mikhail I. Izmestev пишет:
14.04.2011 16:34, Mikhail I. Izmestev wrote:
14.04.2011 16:16, Robert Osfield wrote:
The heart of the problem is that the DDS file format doesn't
distiguish between the
two varients of DXT1, there is an alpha bit in the DDS header that
could be
Hi Mikhail,
I think you have mis-intrepted my suggestion that DTX1a and DTX1c have
essential the same header and contents - I mean in that they are the
same format in memory so we can't distinguish between the two.
One would not expect nvcompress to produce the same output for DXT1a
and DTX1c
If itcan be stored as simple text, the DescriptionList (an attribute of Node) would be the best place for it. UserData is already used by the OpenFlight loader for other things.
The 2.9.x series has a new mechanism for storing such application-specifc data in the scene graph, but if you use
Hi all,
I'd like to ask for feedback about something concerning osgOcean. We've
been using it in multiple views for a while now, only activating the
reflection effect, and it has worked well. We knew that one view would
control the LOD of the ocean tiles (seems to be the last one rendered,
Hi,
Thanks Paul for your answer. I am looking into that.
But what would be wrong with storing such non-visual properties as a new type
of state set attribute?
Regards,
Robert
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38469#38469
Hi, I am also getting a similar error for another lib, although I have added it
at the linker input, when I build I get:
libboost_system-vc90-mt.lib(error_code.obj) : error LNK2019: unresolved
external symbol __imp___invalid_parameter_noinfo referenced in function
public: virtual class
On 4/14/2011 8:29 AM, Anastasia Papas wrote:
Hi, I am also getting a similar error for another lib, although I have added
it at the linker input, when I build I get:
Unhandled exception at 0x7c812afb in Template.exe: Microsoft C++ exception:
std::bad_alloc at memory location 0x0012f32c..
StateAttributes issue OpenGL commands to affect the appearance of renderedgeometry.OSG uses StateAttributes to sort your geometryduring cull and draw.My understanding of your FLT material codes is that they are application data that don't map directly to OpenGL commands.(Perhaps indirectly: your
Paul,
Thanks again for the reply.
Indeed, my main concern was the fact that storing the data as a stateset
attribute could mess-up other things mainly the state sorting for rendering.
On the other hand, storing these values as descriptions for geodes would mean
that this data would be stored
Hi Robert,
I guess I'll use the DescriptionList then. :|
You could also use the DescriptionList of the StateSet...
If the SMC follows say a texture or a material, and is generally
inherited from the top down like state attributes, that might be a way
of doing it. It won't be an actual
On 4/14/2011 9:28 AM, Jean-Sébastien Guay wrote:
You could also use the DescriptionList of the StateSet...
Or, even better, the DescriptionList of any node that is a parent of the
Geode.
--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Digital
Hi Chris, Robert,
You could also use the DescriptionList of the StateSet...
Or, even better, the DescriptionList of any node that is a parent of the
Geode.
I was suggesting the StateSet because if the SMC naturally follows a
texture or material, then it might be more natural that it be
You could also use the DescriptionList of the StateSet...
One of the default osgUtil::Optimizer flags is SHARE_DUPLICATE_STATE. So if two StateSets are otherwise identical and would be shared under this optimization, adding a different material code to the description list of the two StateSets
Hi Paul,
One of the default osgUtil::Optimizer flags is
SHARE_DUPLICATE_STATE. So if two StateSets are otherwise identical
and would be shared under this optimization, adding a different
material code to the description list of the two StateSets would
impair that
WOW! Silly me :-/ I am such a newbie :-D
I was using all of the libs in both modes (e.g. osg.lib and osgd.lib) I guess I
shouldn't have had!!
I removed the ones without -d in the ending, and now everything links, compiles
and RUNS!! Well until next bug comes across ;-)
Thank you so much!!!
Hi Paul,
J-S -- Good catch on the Optimizer issue, dropping the DescriptionList
of StateSets when they become shared. Seems like a possible bug.
Unexpected behavior, at the least. After all, the word DUPLICATE is in
the name of the flag.
That's semantics :-) It may be argued that the
Hi,
Just a small point worth mentioning... The osg::StateSet class does not have
any members of type DescriptioList, at least not in OSG 2.8.3.
Only osg::Node and derived classes have a DescriptionList as far as I can tell.
So in this case, I can't add the data to the StateSet because there is
Hi Robert,
Just a small point worth mentioning... The osg::StateSet class does not have
any members of type DescriptioList, at least not in OSG 2.8.3.
Only osg::Node and derived classes have a DescriptionList as far as I can tell.
Hah, a small point but well worth mentioning!
Somehow I
Jean-Sébastien,
Do you have a link to that thread?
I think there was some discussion about turning UserData into a
container for various types of metadata... Or was that the description
list? :-)
Anyway, I am inclined to think that there are many cases such as mine, when
users want to
Hi Robert,
Do you have a link to that thread?
It started here:
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/65022
But I don't get why gmane seems to have broken up the thread into
multiple threads. There is more discussion here:
Do you have a link to that thread? I think there was some discussion about turning UserData into a container for various types of metadata... Or was that the description list? :-)
This was, in fact, the development on trunk I mentioned in my first reply in this thread. If you're on 2.8.x, it
Hi all,
Thanks for all the feedback.
In case you are interested, I have made a patch for the OpenFlight plugin so
that it reades/writes the surface material code (SMC) and feature id (FID) and
stores it as a description of the geode that contains these attributes.
The format of the description
31 matches
Mail list logo
