Re: [osg-users] Image::computeImageSizeInBytes bug
Hi Robert Marcin, Just a little note: The submission called DDS - Crash fixes, improved handling of S3TC-DXTC has something related with this topic. I guess both should not interfere, but they may be complementary. -- Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Fri, 08 Feb 2013 20:44:06 +0100, p...@ai.com.pl a écrit: On Fri, 8 Feb 2013 16:41:42 +, Robert Osfield wrote: Hi Marci, On 6 February 2013 14:57, Marcin Prus p...@ai.com.pl wrote: Robert, problem I found is different from the one discussed about math/cmath/log etc. and I can confirm it still exists in current version. Algorithm is wrong, computation doesn't take block nature of some compressions into account and fails for last mipmaps in non square textures (size computed is smaller then single block size). My solution is to use code from dds plugin instead of one introduced in image.cpp. This way we have single function instead of two of them and new one (from old dds plugin code) works properly. Could you post the changes you've made to address the problem to osg-submissions, I've checked I don't have any record of other submissions dealing with this issue so if you did send one alas I didn't get it. Robert, I can still see my original post on the submisstion list dated 07.01.2013. I've just sent it again, hope it will get to you this time. I think it may wait for approval because of attachments size, I think it did last time. Best, Marcin Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Questions/proposal for readImageFile() - Detect unloaded images
Hi all, Here is a problem to solve : how can you highlight surfaces where textures didn't load properly (missing file, read error...)? My first answer was to create a ReadFileCallback, and make readImage() encapsulate default call. If call fails, then I return a dummy image (1x1 pixel, flashy color, such as magenta). However this doesn't work, as readers may call readImageFile() multiple times. Ex: image = readImageFile(path1); if (!image) readImageFile(path2); if (!image) etc... In my case, readImageFile(path1) returns either the normal image, or the dummy one (path2 is never tested). I propose to add some stuff to allow a ReadFileCallback to know a bit more about where the caller is. I'd like to know if you have any idea... Here are mine : 1. In all readers, call readImageFile() in the last case (or another method such as Registry::readImageFileFailed()), so that ReadFileCallback knows all other calls failed. Just ugly, I think. 2. In all readers, add something in the osgDB::Options structure in their last call, for the same purpose. Ugly too. 3. Change readImageFile() / ReadFileCallback to pass an additional parameter. Very ulgy! 4. In all readers, add a ValueObject (or something else) to record the fact loading failed. This would allow post-load code to detect this info. As you can see, I got no clean idea. Please help ! Cheers, Sukender ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] ReaderWriter X reworked
Hi Ulrich, I also spotted the missing ''. You're absolutely right. Well, if you already fixed them you can submit ^^... or else I'll do (but sincerely I don't know when...) Cheers, Sukender - Mail original - De: Ulrich Hertlein u.hertl...@sandbox.de À: OpenSceneGraph Submissions osg-submissi...@lists.openscenegraph.org Cc: Sukender suky0...@free.fr Envoyé: Jeudi 14 Juin 2012 15:52:30 Objet: Re: [osg-submissions] ReaderWriter X reworked Hi Sukender, I had a quick look at the patch and checked that it still works with the various .x files I have flying around. One thing I did notice in the code is that you're passing 'const std::string' in some places. For the sake of efficiency these chould be replaced with 'const std::string' to avoid making a copy every time. Same for passing 'osg::Vec', these should always be passed as const-ref unless they are modified or returned. Maybe this is something you could fix and resubmit? Apart from that I'd say it's good to go. Just my $0.02 Cheers, /ulrich On 31/05/12 11:14 , Sukender wrote: And now the patch. It is about .X: - Brand new writer for .x format. Yes, the format is deprecated but some still use it. Current implementation has limitations (only supports one texture, for instance) but works. - Reader - Added checks, warnings, and crash guards - Now handles FrameTransformMatrix element (kind of osg::MatrixTransform) - Fixed CW / CCW for faces - Better handling of materials (handles meshes with no materials, fixed reading of transparent textures...) - Handling triangles and polygons differently - Reader can now create indexed geometries - And more... The reader clearly doesn't read 100% of .x files, but handling is way better now. Sorry for the huge amount of changes, but these are the result of many commits from a colleague, and giving you these commits separately won't help you merge the code as the 1 commit = 1 feature rule was not followed at all... Cheers, Sukender ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Incorrect normals calculated on 3DS import
Hi Alexey, Loaded models are perfectly valid, and most users are okay with per-vertex normals. However, you seem to need a different representation. I don't have code to share witch would generate per-face normals, but this is quite straightforward. Look at the Newell method to generate normals. Or look at osgModeling, but I think it's a per-vertex basis too (however you can choose between different algorithms if I remember well). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Alexey Chernov 4er...@gmail.com a écrit : Thank you, Sukender, But can you suggest to some universal way to get valid model from 3DS in OSG? For example, is it possible to calculate normals in PER FACE mode. What's the common way to workaround problems with 3DS-imported models in OSG? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41236#41236 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Incorrect normals calculated on 3DS import
Hi Alexey, The 3DS format doesn't store normals, and the reader thus generates default normals PER VERTEX (and not per face), using a kind of smooth eveything algorithm. It fits many usages but it is clearly not adapted to your model. You may find algorithms to recompute them, but I'm not a Blender expert at all... good luck ;) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Alexey Chernov 4er...@gmail.com a écrit : Hi, I tried to load a model from 3DS file and found that it has some strange lighting effect both in osgviewer and in my application: on model's borders there're dark areas and it seems as if there're low of polygons (a screenshot and model are attached). I was suggested that the problem is with normals which are inverted to inside the model. So, I've got 2 questions: 1. Is it right that the problem is caused by normals (as I found in 3ds plugin code, they are calculated on the fly)? 2. Can I fix them somehow after the model is loaded? For example, is there an easy way to perform something like Recalculate Normal Outside in Blender? Thanks in advance for any information! Regards, Alexey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41137#41137 Attachments: http://forum.openscenegraph.org//files/can_172.zip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, hi all, Sorry for being silent these days... I just got back on the OSG development. Well I've read your posts and I must admit I'm a bit disapointed because proposed changes seem rather radical to me, and implies some features will be dropped/reduced... The backwards compatibility support for UserData looks like it'll introduce a memory leak Ok. You're right. Sorry! For the existing UserData and DescriptionList I'm currently inclined to hardwire this into ValueContainer as getUserData() and getDescitionList(). This is a bit clunky but it'll be less complicated trying to adapt both of these into osg::Object. I did not understand why you hardwired userData and descriptionList instead of letting them be metadata as any other. I don't think this is less complicated. On the contrary, I feel we must factorize code as much as possible. And this seems akward to me because this forces to have more lines of code, and thus have more things to debug. I feel more confortable with less methods and less lines of code, don't you? BTW, moving descriptionList availability from Node to Object seems not a good idea as we're trying to make them disapear. However this may centralize metadata to one place, so why not, as long as deprecation is clear and explicit...? This is subject to discussion! The idea of having a ValueBase class which only provides the Referenced class and a local clone() seems rather too minimal. Object has clone functionality built into it and hooks into the OSG's serializers I'm quite in favor of using osg::Object as a base for metadata, especially for serialization. But the fact it already stores a name is problemetic when you want your data to be indexed by name, or if you wish your data be put in a database backend. For instance, using a map would require names duplicaion (one in the map, one in osg::Object), or a strange mapstring*, Object, string pointer compare thing. Any opinion/idea on this? Mine is that an osg::Object without name would be ideal, but this would bring another class! Unless we move the name as a metadata too? Well this could be a nice idea: some meta names would be reserved, and especially one for the name, one for userData, and one for descriptionList. Thoughts? I also wonder if perhaps ValueContainer and ValueContainerMap might just become oen class ValueMap I'm not in favor of this. Grégoire and I explicitely made two classes to let the user choose the container. Especially we wanted to let database backend (a requirement of some OSG users) be easy to plug. As Peter told, I guess the ability to subclass a custom UserDataContainer implementation is important. However I uderstand your point of view on sharing containers, especially regarding to serialization. So what about something not sharable, but which user can subclass? Another route for adding extra flexiblity would be to just subclass your own user data scheme from osg::Object and assign it as UserData or as UserObject The proposal of putting a user-defined container as a metadata may solve the problem but seems also a bit a burden for the user. The container used within ValueContainer could be an std::vectorosg::ref_ptrosg::Object to allow indexing via a conventional array style access The proposal of a vectorref_ptrObject seems okay for a default implementation (instead of a map). You're right about trying to keep the class count down (and my implementation is certainely not optimal), but I keep thinking the container should be customizable and I would keep the ValueContainer class. As a conclusion, I can say this subject is not closed yet! ;-) Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Peter, I'm open to suggestions on making the implementation more flexible, however, any extra complexity has to be strongly justified - i.e. with concrete usage case, so could you flesh out what you'd want to do with the subclassing from UserDataContainer. Another route for adding extra flexiblity would be to just subclass your own user data scheme from osg::Object and assign it as UserData or as UserObject, then do a dynamic cast to get access to your custom implementation. Currenly you can share UserData and UserObjects between their owner osg::Object. As for sharing whole UserDataContainer objects between their owner osg::Objects, this is something I considered and implemented initially but then decided to make things simpler and just have an internal data container subclassed from osg::Referenced. Adding the capability of sharing UserDataContainer won't be difficult, but will require us to push the declaration of the UserDataContainer into the public scope something that will constain how flexibile we can be with the implementation and it's interface, and would require us to implement UserDataContainer
Re: [osg-users] Meta-data in core OSG - project started
Hi DJ,
You're welcome! And thank you for exposing your thoughts.
Well, you're right, the problem has always been there. And of course,
removing the container will remove userData and descriptionList. However I
think that a developer removing the container MUST know what (s)he's doing. You
must not blindly remove it hoping userData and descriptionList will be kept.
Maybe this would require additional documentation? And maybe we could provide a
function to clear all but things for backward compatibility? For instance:
/// Empties a container from all but userData and descriptionList, for
backward-compatibility.
void clearValuesButUserDataAndDescriptionList(osg::ValueContainer vc)
{
Iterate over values
if value isn't userData or descriptionList, remove it
}
/// Removes the container of an object and replaces it with a default one, and
also keeps userData and descriptionList, for backward-compatibility.
void removeContainerButKeepUserDataAndDescriptionList(osg::Object o)
{
if (o has no userData nor descriptionList) { Remove ValueContainer from
'o'; return; }
Create a new (default) container
Copy user userData pointer and/or descriptionList from old container to the
new one
Add new container to 'o', replacing the old one
}
But clearly your project may benefit from being ported to the new metadata
system, as our project is currently being. You'll not suddenly gain astonishing
features, but at least you'll have something which will not interfere with
existing 3rd-party meta and/or userData and/or descriptionList.
Maybe we should put this discussion (once finished and summarized) in a v6 of
the document?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- D.J. Caldwell dlcaldwel...@gmail.com a écrit :
Hi Gregoire, Sukender, and everyone,
While writing this email, I have come to the conclusion that I/we do
not really have anything (more) to be concerned about with tying user
data and description list to the meta-data system. If you are
interested in some of the concerns I already had, and that were
further clarified while reviewing the proposed meta-data system, read
on. I appreciate the responses I have received thus far. Again, thanks
for all the hard work! :-)
...here is what I was thinking...
My concern is not so much that the underlying structure will be
unavailable, per se. It is that userData and descriptionList will now
be tied to the meta-data system, with no built in alternatives. With
the proposed implementation, replacing an existing meta-data container
would effectively clear any existing userData or descriptionList.
Further, if the special hooks for exotic types are part of the
container, and that container is not written to handle generic data
such as userData and descriptionList, use of userData/descriptionList
may cause problems.
Really, I am just trying to make sure I/we understand all the
implications of tying userData, descriptionList, and meta-data
together in the same core feature.
Here is one problem scenario that I have some concern about:
[code]
// load some data
osg::Node* p = osgDB::readNodeFile ( ... );
...
p-addDescription ( ... );
...
// if the following third party function calls setValueContainer,
// this destroys any existing userData and/or descriptionList
thirdParty::doSomeWork ( p );
[/code]
In my project, we have been using descriptionList as a work-around to
userData and the fact that each osg::Node is restricted to not more
than one attached instance of userData. I did not want to interfere
with any existing userData generated by geometry and scene files, so I
used descriptionList to store our runtime data, because
descriptionList appears to have no explicit restrictions beyond that
of a std::vector. If a third party function happens to cause the
description list to be cleared after we have added some data to it, we
would lose the data we need to do some of our runtime work.
In reality, the proposed meta-data system does not cause the above
problem scenario; the problem has always been there (the third part
function could have directly called setDescriptions). However, this is
one more way to clear the description list.
I suppose, in the end, there really is no need for my concern. You
propose (or I have inferred) a required interface with specific
guaranteed behavior for writing custom containers; if container
providers follow the rules, userData and descriptionList (or whatever
a client may want to use) will still be supported. As long as no one
takes the opportunity to replace an existing meta-data container
without documenting that this is what they are doing, we should be
fine.
I will review version 5 of your document, and I will give myself some
more time to digest what you have written. I already like what I have
seen, and the more that I think about it, the better understanding I
Re: [osg-users] Meta-data in core OSG - project started
Hi Sergey,
Thank you for the links.
You're right when saying variant causes a lot of issues. I won't bring an
answer about Variant here, but just some points about the current design:
I must say I wondered about adding a support for basic types (conversion
from/to int/string/double...). The question is: which types should be
considered as basic? fundamental types only? string? vectorstring?... Well it
depends on the usage actually. And the problem with a variant, as described in
trac.rtmpd.com, or the one in boost.variant, is that you must know (into OSG)
all the types you'll use beforehand. Which is pretty impossible regarding to
the different uses.
This is why I preferred something very neutral (hence osg::ValueBase). Of
course another problem arises: it's very common to need the type of a ValueBase
to get its (casted) value, or trigger specific code, etc (as specified in
section 3 of the PDF you sent the link). For now, and using current
implementation draft, we wrote a simple (yet very slow) solution with
dynamic_cast:
unsigned int getType(...) {
if (dynamic_castosg::ValueTYPE_1*(p)) return ...;
if (dynamic_castosg::ValueTYPE_2*(p)) return ...;
// etc.
}
This is clearly too slow if you call the function too ofen. Fortunately for us
this seems not critical at all. And this is less memory consuming creating a
TypedValueBase class, storing an integer (for instance) indicating the type.
But this may be useful to some developpers which often ask for the type of a
value. The base class would then look like:
class TypedValueBase : public ValueBase
{
public:
typedef unsigned int ValueType;
ValueType getType() const { return _type; }
protected:
ValueType _type;
};
or
class TypedValueBase : public ValueBase
{
public:
typedef unsigned int ValueType;// Should this be a string?
virtual ValueType getType() const =0;
};
or you may imagine the same virtual methods as Node (className(),
libraryName(), etc...)
Then using this base class you could create, say, TypedValueInt,
TypedValuePotato, etc.
Do you think this should be provided in core OSG alongside (and as an
alternative to) ValueT? Which version of TypedValueBase do you prefer?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sergey Kurdakov sergey.fo...@gmail.com a écrit :
Hi Sukender,
concerning Variant,
for simple types
something like
http://trac.rtmpd.com/browser/trunk/sources/common/src/utils/misc/variant.cpp
http://trac.rtmpd.com/browser/trunk/sources/common/include/utils/misc/variant.h
http://trac.rtmpd.com/browser/trunk/sources/common/include/utils/misc/variantmap.h
might go,
but it looks like you would like more, then discussion here
http://stackoverflow.com/questions/5319216/implementing-a-variant-class
( esp use of boost variant instead of boost any ) might be of some
use.
My concern though is about speed of dynamic cast ( which is slow ), so
maybe sort of custom rtti ( see example
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=C4231214774C16E32EA2B2C879DAACB3?doi=10.1.1.164.1009rep=rep1type=pdf
) could be used here...
but if custom rtti
here comes to mind http://www.rcs.hu/Articles/RTTI_Part1.htm
http://www.rcs.hu/Articles/RTTI_Part2.htm and then both osgReflection
(now osgIntrospection ) and Wang Rui's reflection wrappers should be
considered as they already have some functionality.
so simple question of variant ( and degree of it's complexity and it's
speed and then maybe serialization of very special variant ) causes a
lot of issues to surface.
Regards
Sergey
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, hi all,
We're working on impementing the meta-data system. We found that there was very
few feedback, and feel it's a bad sign of inacceptance of it... Anyone?
Peter, when you told about immutability, it was with a database backend in
mind, right? If so, I think it may be better not to have immutable Values.
Indeed, DescriptionList and more generally user data may be mutable. So to get
this database backend wokring properly, I think one should:
- Define a ValueDB, derivate from ValueBase.
- Define a DBProxy, derivate from ComponentContainer (well, we renamed it
ValueContainer to avoid misinterpretation)
- Make DBProxy give ValueDB when getting
- Make ValueDB know DBProxy so that modifying a ValueDB will call appropriate
method in DBProxy
- Make DBProxy also accept ValueT as an input, and convert it to appropriate
SQL/request/whatever
Thoughts?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi all,
From your feedback and our first tests/prototypes, here is the revised
document.
Please comment!
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Peter Amstutz peter.amst...@tseboston.com a écrit :
Immutable means cannot be changed. So I mean that the Value
class
should not have a set method and all get methods should be
const.
E.g.
templateT
class Value {
private:
T v;
public:
Value(const T _v) : v(_v) { }
const T get() { return v; }
// type conversion operator, so you can write
// Valueint a(5);
// int b = a;
const T operator T () { return v; }
};
On 4/19/2011 5:46 AM, Sukender wrote:
Hi Peter,
Okay, we'll certainely try your ideas. I guess ValueBase is meant
to
be derived, but ValueT isn't.
However, I'm not sure I understand the immutable thing. Do you
mean you preference goes to
function( someParam )
rather than
function( ValueSomeType(someParam) )
?
If so, yes. And that's of course easier to write and read.
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Keep up the good work :-) Nice to read it, Robert! ;) And you're right, keep your mind resources for all other important things here! Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Wed, Apr 27, 2011 at 3:09 PM, Sukender suky0...@free.fr wrote: We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? I don't have any comments beyond what others have added so I've been happy to sit back and watch the discussion evolve. I have enough other work to think about so rather than get wrapped up in another topic I am deliberately kept my head down so I can keep my brain capacity and time from being too thinly spread. So me being quiet is not in-acceptance or disinterest, but comfort that all those who've been contributing to the thread look to be going in a resonable direction and don't seem to need any guidance from me. Keep up the good work :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Thanks DJ. I must say the conversion of our project to the new meta-data system is not that instant... Hopefully the code is 99% backward compatible and the use of userData and Description list still work as expected. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - D.J. Caldwell dlcaldwel...@gmail.com a écrit : Hi Sukender, I, too, have been following this thread with interest. I have not had the time or resources to go over your documentation, yet, but I hope to do so soon. In my current project, we have adapted the osg::Node::DescriptionList to store some basic run time data at the node level. My hope is that the meta-data system you all are designing will give us a more type safe option that does not require string conversion. Thanks for taking the time and effort to work on this. Even if this turns out not to be the solution I am looking for, I am sure others will be able to leverage it to great effect. D.J. On Wed, Apr 27, 2011 at 10:23 AM, Sukender suky0...@free.fr wrote: Keep up the good work :-) Nice to read it, Robert! ;) And you're right, keep your mind resources for all other important things here! Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Wed, Apr 27, 2011 at 3:09 PM, Sukender suky0...@free.fr wrote: We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? I don't have any comments beyond what others have added so I've been happy to sit back and watch the discussion evolve. I have enough other work to think about so rather than get wrapped up in another topic I am deliberately kept my head down so I can keep my brain capacity and time from being too thinly spread. So me being quiet is not in-acceptance or disinterest, but comfort that all those who've been contributing to the thread look to be going in a resonable direction and don't seem to need any guidance from me. Keep up the good work :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, Your analysis seems fine. However, I must add a precision: In the current design, there is a ValueBase class (actually an empty class derived from Referenced). This way it's a bit easier dealing with values as the base class is not templated. Well, not something enough to change your mind! :-) I understand your choice, but fear that simple uses may be not straightforward to understand for OSG beginners, or simply for OSG users that don't want/need to have complex systems. So my feeling is better a simple thing that may be complexified by advanced users, even if it's a bit difficult, rather than a less straightforward system. As an advanced user, it's a frustration and heartbreak to say okay, let's go for a system with less features, but there will always be more beginners than experts... don't you think? However I don't wan't the system to be tied exclusively to simple uses only. Yes, having a database backend may not be that simple, but I want this to be possible. For instance, we're currently coding first things and found it was a good thing to let the container know about its parent objects for this DB backend. So the Object::setValueContainer() looks like: tell the current container we're detatching replace the current container with the new one tell the new container we're attaching I guess some little things like this may help creating a DB backend. And after all, why not having an osgMySQL or osgPostGre later on, as both an out-the-box default DB backend and a model for other ones? BTW, I think next steps on our side are: 1. Finish the first implementation (almost done) 2. Convert our project to use these new metas, to check everything goes fine. 3. Debug 4. Send OSG modified files on the mailing list (osg-users) for a first review. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : Sorry about that, you sent out the previous email on the weekend and I didn't have a chance to look at it; when Monday rolled around I had forgotten about it. Regarding the Value class, I think I understand the difference of opinion a little better. Let me present both sides. // Option A. Value types are osg::Referenced and mutable osg::ref_ptrValueint v = container-getMetaint(foo); assert(v-get() == 3); v-set(5); assert(v-get() == 5); - A value object can be held by many nodes. Changing it in once places affects all nodes. - Similar to how other reference counted elements of the scene graph work, e.g. osg::Uniform - ValueT will probably need a parent list to track its owners - Awkward to map metadata values onto a database. In addition to getMeta() and setMeta(), must derive from ValueT or come up with a callback interface to tie to the data store. - Potential for race conditions if a thread changes the contents of value while another thread is using it // Option B. Value types are not refcounted and immutable Valueint v = container-getMetaint(foo); assert(v == 3); node-setMetaint(foo, 6); assert(v == 3); assert(node-getMetaint(foo) == 5); - A value object cannot be held by multiple nodes. If you want to logically share a value across nodes, must store a pointer or id into a separate table as the value. - Similar to non-reference counted elements of the scene graph. - ValueT can be very simple and doesn't need to track or backreference anything. - Straightforward to map to a database, only need to implement getMeta() and setMeta() - No race condition concerns. Laying it out like this, I could support a design going either way. However my instinct is to prefer immutable data structures as a general rule as they tend to reduce programming errors (especially when threads are involved). I also think the metadata facility should be simple and easy to extend by implementing a new MetadataContainer class rather than putting in complicated hook/callback/proxy mechanisms that try to handle everything. I think the next step should be to put together some header files / class definitions so that we can discuss the proposed API in specifics. - Peter On 4/27/2011 10:09 AM, Sukender wrote: Hi Peter, hi all, We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? Peter, when you told about immutability, it was with a database backend in mind, right? If so, I think it may be better not to have immutable Values. Indeed, DescriptionList and more generally user data may be mutable. So to get this database backend wokring properly, I think one should: - Define a ValueDB, derivate from ValueBase. - Define a DBProxy, derivate from ComponentContainer (well, we renamed it ValueContainer to avoid misinterpretation) - Make DBProxy give ValueDB when getting - Make ValueDB know DBProxy so
Re: [osg-users] New FBX SDK
Hahaha! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Chris 'Xenon' Hanson xe...@alphapixel.com a écrit : On 4/22/2011 6:05 AM, Sukender wrote: I think I'm going to hang myself... That's a known side effect of FBX. And COLLADA. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New FBX SDK
I think I'm going to hang myself... I just hope there will not be too much problems. Unfortunately, I will not be able to test your sumbission right now, I'm sorry. I'll tell you when I can. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Michael Platings mplati...@gmail.com a écrit : Hello FBX plugin users, Autodesk have released version 2012.1 of the FBX SDK, and I've now updated the plugin to work with it - source attached. The new SDK has deprecated/removed several features used by the plugin so to get it working again I've had to make non-trivial changes that may break loading/saving some files. I've tested with a wide range of files but more testing will be appreciated :) The SDK's directory structure and library names have changed and as I don't know the default file locations on Mac Linux I need help adding those to FindFBX.cmake . I'll delay actually submitting the changes for a while to give you guys time to fix the Mac Linux paths and test/fix any bugs that may have been created. Thanks -Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Sergey, Thanks for the link. However I think the entity thing is far more high level than just metas. Are you thinking about something specific metas should support? If so, I would certainly try to insert the requirements. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sergey Kurdakov sergey.fo...@gmail.com a écrit : Hi Sukender, while not directly, but very related project is http://sourceforge.net/apps/mediawiki/delta3d-extras/index.php?title=DtEntity take a look, maybe few ideas could be used. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter and Sergey, Well for now serialization of userData is made blindly. I guess unsafe things will be serialized the same way. And yes, I guess metadata will be a base for more applications, but as long as there is no hard requirement in the basement, I don't think about coding things towards actor/entities management in a first implementation. Don't you think, Sergey? Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : I think the metadata system under discussion will be useful for associating scene graph nodes with their owner entities. This is necessary for various scene-graph oriented operations like picking, custom culling, etc that need to refer back to your application domain entities . You certainly could use it to store your entity components, but that should be up to the user. I think we need to be careful to avoid scope creep. This discussion does bring up one related issue, though. Regarding serialization, I had been thinking that the metadata system should only be allowed to contain data that can be safely serialized. I realize now that is wrong, for precisely this issue that the metadata system will be used to hold pointers to application domain entities that are opaque to the serialization system. Peter On 4/20/2011 8:30 AM, Sergey Kurdakov wrote: Hi Sukender, However I think the entity thing is far more high level than just metas. that is correct. still there is need to assemble metas as objects into something useful and also exchange info ( message system ). this functionality might be a separate addition, but it's presence ( or considering it's use with metas; I'm not sure, but it might add some additional fields, methods etc ) will greatly extend 'use' cases to jump start to apply your metas in projects. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter,
Okay, we'll certainely try your ideas. I guess ValueBase is meant to be
derived, but ValueT isn't.
However, I'm not sure I understand the immutable thing. Do you mean you
preference goes to
function( someParam )
rather than
function( ValueSomeType(someParam) )
?
If so, yes. And that's of course easier to write and read.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Peter Amstutz peter.amst...@tseboston.com a écrit :
You could use an implicit constructor, e.g.
templatetypename T
class Value {
Value(T);
Value(const ValueT);
};
class Valueint;
templateT
void addMeta(const std::string, const ValueT v) {
ValueT* localcopy = new ValueT(v);
}
so the function call:
addMeta(myMeta, 5);
is implicitly converted to:
addMeta(std::string(myMeta), Valueint(5));
Two considerations:
- There is some copying involved, which might be undesirable for
large
arrays. C++ 2011 move constructors are intended to solve this
problem
in general, but it's unlikely that OSG compatibility requirements
will
allow the use of C++ 2011 features for a while.
- The way it is described here, any customization for ValueT must
occur through template specialization, rather than subclassing. To
support subclassing, use a clone() method instead of new ValueT(v).
On a related note, my preference would be for the ValueT class to
be
immutable so that you are required to set metadata values through the
API rather than poking ValueT objects directly. This is necessary
if
you want to support alternate backing stores which don't use ValueT
objects in the backend at all.
- Peter
On 4/15/2011 11:10 AM, Sukender wrote:
Hi Peter,
Thanks... but what for the addMetaT()?
I mean it's okay having a addMeta(string, ValueBase *), but this
will force you to write
o-addMeta( myMeta, new Valueint(5) );
instead of simply
o-addMeta( myMeta, 5 );
which could be nice. Any idea?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
hmmm...
Why did you write
templateT void addMeta(const std::string, const ValueT v);
?
Wouldn't this be simpler:
templateT void addMeta(const std::string, const T v);
?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Peter Amstutz peter.amst...@tseboston.com a écrit :
You could use an implicit constructor, e.g.
templatetypename T
class Value {
Value(T);
Value(const ValueT);
};
class Valueint;
templateT
void addMeta(const std::string, const ValueT v) {
ValueT* localcopy = new ValueT(v);
}
so the function call:
addMeta(myMeta, 5);
is implicitly converted to:
addMeta(std::string(myMeta), Valueint(5));
Two considerations:
- There is some copying involved, which might be undesirable for
large
arrays. C++ 2011 move constructors are intended to solve this
problem
in general, but it's unlikely that OSG compatibility requirements
will
allow the use of C++ 2011 features for a while.
- The way it is described here, any customization for ValueT must
occur through template specialization, rather than subclassing. To
support subclassing, use a clone() method instead of new ValueT(v).
On a related note, my preference would be for the ValueT class to
be
immutable so that you are required to set metadata values through the
API rather than poking ValueT objects directly. This is necessary
if
you want to support alternate backing stores which don't use ValueT
objects in the backend at all.
- Peter
On 4/15/2011 11:10 AM, Sukender wrote:
Hi Peter,
Thanks... but what for the addMetaT()?
I mean it's okay having a addMeta(string, ValueBase *), but this
will force you to write
o-addMeta( myMeta, new Valueint(5) );
instead of simply
o-addMeta( myMeta, 5 );
which could be nice. Any idea?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi JS, About other serializers (Collada, FBX...), I guess it would be nice using the OSG serialization (as you say), or a default/fallback one. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit : Hi Sukender, Actually I hoped someone would help us on the serialization subject! And yes, I guess new serializers may help. I think so, I haven't used them that much but from the description they seem simple to use, and as long as the class you want to save is serializable then when the osg::Object serializes itself it can serialize all its metadata at the same time. But what about formats supporting metas? It may be helpful to add somewhere a callback/serializer/anything, which may be called by plugins to convert from/to a string representation when not handled natively. No? Ah, so you're talking about saving to formats other than .osgt/.osgb right? In that case perhaps the same serializers can be used to serialize the metadata, and then put that in a string inside metadata of the other format file. And then when reading you just check if one of the metadata in the file corresponds to some OSG-serialized data, and deserialize it. That could work. And if the format has additional data that OSG doesn't know about, but which the reader might want to store as metadata in the OSG nodes when reading the file (like the recent discussion about OpenFlight Surface Material Codes), the ReaderWriter can easily add metadata when reading too. But I think perhaps loading/saving metadata to/from OSG-native formats would be enough for now... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, Well observed. We'll add methods to iterate and a pointer to object. But we just spotted a flaw in our design: we wrote some virtual templated methods (which is impossible of course)... Any idea on how to return a T* in ComponentContainer::findFirstMeta()? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : My initial impression is that this seems pretty well thought out, but a little incomplete. Some comments: - The ComponentContainer interface is lacking a way to iterate over all values. - The add/find/delete methods on ComponentContainer should take the owner osg::Object as a parameter. This is necessary if you want to share a single ComponentContainer instance across many nodes, for the case where the ComponentContainer is actually a front end to a separate data store. - For serialization, storing simple value types is pretty straightforward. The harder part is dealing with compound types (structs/classes) and/or containers (map/vector). Perhaps there is a way to leverage osgIntrospection? On 4/15/2011 6:30 AM, Sukender wrote: [cross-post osg-users/osg-submissions] Hi Robert, hi all, We often discussed about handling name-value pairs in core OSG. Now it's time for action! Grégoire Tarizzo and I wrote a first specification document about a metadata system. We would like you (I mean all those interested in the subject) to review it and give your feeling and feedback. Please take this document as an advanced proposal. We *WILL* for sure code a first version of the meta-data system. But even if we tried to cover most aspects and most usages, wee need you to ensure this submission to be widely accepted. Thank you very much. Happy reading! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi J-S, Actually I hoped someone would help us on the serialization subject! And yes, I guess new serializers may help. But what about formats supporting metas? It may be helpful to add somewhere a callback/serializer/anything, which may be called by plugins to convert from/to a string representation when not handled natively. No? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit : Hi Peter, - For serialization, storing simple value types is pretty straightforward. The harder part is dealing with compound types (structs/classes) and/or containers (map/vector). Perhaps there is a way to leverage osgIntrospection? I think the new serializers make it simple to make new classes serializable... If the requirement is simply that a class added as metadata needs to be serializable that way, it would take care of that problem right? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, Thanks... but what for the addMetaT()? I mean it's okay having a addMeta(string, ValueBase *), but this will force you to write o-addMeta( myMeta, new Valueint(5) ); instead of simply o-addMeta( myMeta, 5 ); which could be nice. Any idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : Put the dynamic_castT inside the method. On 4/15/2011 10:53 AM, Sukender wrote: Hi Peter, Well observed. We'll add methods to iterate and a pointer to object. But we just spotted a flaw in our design: we wrote some virtual templated methods (which is impossible of course)... Any idea on how to return a T* in ComponentContainer::findFirstMeta()? Sukender -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osg Dae plugin error: Texture coordinate set 0 not found
Hi Anastasia, I guess you did not understand what I wrote... I suggest to get the source files I submitted, and recompile the Collada plugin with them. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Anastasia Papas hyper_pon...@hotmail.com a écrit : Hello Sukender, Thank you very much for your reply! I went through my collada file and all I found related to either unit which you suggested should change are the following two lines: unit name=inch meter=0.0254/ wire_units0/wire_units And then I looked for texture too: texture texture=V4SmplTorsoM_BKN_jpg-sampler texcoord=CHANNEL1/ bind_vertex_input semantic=CHANNEL1 input_semantic=TEXCOORD input_set=0/ input semantic=TEXCOORD source=#geom-Victoria_4.2-map1 offset=2 set=0/ I don't know to which of all you were refering that should change, but anyway all of the are set to 0. Please help me, I am really stack on this for long time and I have no idea how to fix it :-/ I really need my textures :-| Thank you once again for your time!! Best Regards, Anastasia -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38405#38405 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osg Dae plugin error: Texture coordinate set 0 not found
In the post :) They are attached to the email I sent. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Anastasia Papas hyper_pon...@hotmail.com a écrit : I guess you're right.. I am not really experienced, that's why I am so stuck on this :-( Where can I find the source files you submitted ? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38431#38431 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osg Dae plugin error: Texture coordinate set 0 not found
Hi Daniele and Anastasia, Please have a look at [osg-submissions] Collada reader - Non-empty texture units. I proposed a change which puts all filled textures unit to to zero. Example: when texture units 1 and 2 are filled, they become 0 and 1. This hasn't been accepted (yet?). But please let us know it it solves your issue. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Anastasia Papas hyper_pon...@hotmail.com a écrit : Hi! I am facing the same problem, only difference I am using an export from 3ds max! Did you finally solve this problem and how? Thank you anyways!! Anastasia -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38383#38383 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Flag not reset in TriangleFunctor = bug?
Hi all,
TriangleFunctor reads:
virtual void end() {
//...
_treatVertexDataAsTemporary = true;
drawArrays(_modeCache,0,_vertexCachef.size());
}
So drawArrays know the data is temporary, thanks to the flag. But shouldn't the
flag be reset to false after the call?
_treatVertexDataAsTemporary = true;
drawArrays(_modeCache,0,_vertexCachef.size());
_treatVertexDataAsTemporary = false;
If you got any clue, that could be nice!
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD - Trying to understand climbing mem usage
Hi Robert,
Sorry for being too vague. It's a data preparation + viewer app, but the
problem arises during the data preparation. Some data sets do not present the
symptoms whereas some others do... Here is a more detailed view of the
problematic method, in pseudo-code:
void function(Group parent, const string path) {
If path is a directory
osg::ref_ptrosg::Group group(new osg::Group);
Foreach entry in the directory, do a recursive call: function(group, entry).
write 'group' to disk, in 'groupFile' (somewhere out of the current directory
structure)
Generate a PagedLOD, to load 'groupFile' when below a given view distance
(using group-getBound())
Add that PagedLOD to 'parent'
unload the group (well, it's a local variable!)
else if it's a 3D file
Get the AABB of the 3D file (the file isn't loaded in memory)
Generate a PagedLOD, to load the 3D file when below a given view distance
(using AABB info)
Add that PagedLOD to 'parent'
}
This makes memory rise very high and very quickly on a given dataset. This
dataset is a hierarchical tree structure with at most 1000 3D files in each
dir. What is strange is that the algorithm seems quite straightforward. I'm
just going crazy! I'm pretty sure there is a stupid little thing around here
that I didn't spot. Or is there some OSG internal mechanism I didn't deactivate?
Tries:
- As I told, I wrote (before the method runs)
options = osgDB::Registry::instance()-getOptions();
options-setBuildKdTreesHint(osgDB::Options::DO_NOT_BUILD_KDTREES);
options-setObjectCacheHint(osgDB::Options::CACHE_NONE);
- I also tried adding databasePager.clear(); after writing the 'groupFile',
but this doesn't change anything.
Any idea?
Many thanks.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Sukender,
You explanation of what you are doing in your app is way too light
for
us to be able to guess what might be amiss. Are you running the
viewer? Is it just data preperation? I haven't got a clue.
Robert.
On Tue, Mar 22, 2011 at 5:42 PM, Sukender suky0...@free.fr wrote:
Hi all,
Here's something strange:
- I create PageLODs that will load files on disk when needed
- I create Groups of PagedLODs
- I write those groups to disk (OSGB/T format). They thus contain
only few data (just nodes and paths where data is).
- I create a PagedLOD which loads this newly file on disk. The group
is theorically unloaded after this.
When repeating this, my memory usage climbs very high... but the
groups should not be in memory... I wrote
osgDB::Options * options =
osgDB::Registry::instance()-getOptions();
options-setBuildKdTreesHint(osgDB::Options::DO_NOT_BUILD_KDTREES);
options-setObjectCacheHint(osgDB::Options::CACHE_NONE);
But this doesn't change anything.
And of course I finally run out of memory.
For info, small graphs behave normally in osgViewer (nodes load when
approaching, memory usage rises, etc.).
Any idea?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD - Trying to understand climbing mem usage
Hi Laurens,
Thanks for the tip. But my function looks like:
osg::ref_ptrosg::PagedLOD paged( new osg::PagedLOD );
paged-addChild(new osg::Node);
paged-setFileName(1, pathTo3DFile);
paged-setRange(0, dist, FLT_MAX);
paged-setRange(1, 0, dist);
I create an empty child at index 0, viewable from 'dist' to FLT_MAX. The second
thing is not a child but a range+filename, viewable from 0 to 'dist.
This seems correct to me.
Thoughts?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Laurens Voerman l.voer...@rug.nl a écrit :
Hi Sukender,
Just a guess here,
when you say
Generate a PagedLOD, to load 'groupFile'
do you call PagedLOD::addChild(Node *child, ) ?
for the pageLOD will then hold the child in memory until
PagedLOD::removeExpiredChildren() is called. Normally this is done in
the frame loop (in updateSceneGraph()) but I think you're not in a
frame
loop (yet).
Laurens.
On 3/23/2011 10:19 AM, Sukender wrote:
Hi Robert,
Sorry for being too vague. It's a data preparation + viewer app,
but the problem arises during the data preparation. Some data sets do
not present the symptoms whereas some others do... Here is a more
detailed view of the problematic method, in pseudo-code:
void function(Group parent, const string path) {
If path is a directory
osg::ref_ptrosg::Group group(new osg::Group);
Foreach entry in the directory, do a recursive call:
function(group, entry).
write 'group' to disk, in 'groupFile' (somewhere out of the
current directory structure)
Generate a PagedLOD, to load 'groupFile' when below a given view
distance (using group-getBound())
Add that PagedLOD to 'parent'
unload the group (well, it's a local variable!)
else if it's a 3D file
Get the AABB of the 3D file (the file isn't loaded in memory)
Generate a PagedLOD, to load the 3D file when below a given view
distance (using AABB info)
Add that PagedLOD to 'parent'
}
This makes memory rise very high and very quickly on a given
dataset. This dataset is a hierarchical tree structure with at most
1000 3D files in each dir. What is strange is that the algorithm seems
quite straightforward. I'm just going crazy! I'm pretty sure there is
a stupid little thing around here that I didn't spot. Or is there some
OSG internal mechanism I didn't deactivate?
Tries:
- As I told, I wrote (before the method runs)
options = osgDB::Registry::instance()-getOptions();
options-setBuildKdTreesHint(osgDB::Options::DO_NOT_BUILD_KDTREES);
options-setObjectCacheHint(osgDB::Options::CACHE_NONE);
- I also tried adding databasePager.clear(); after writing the
'groupFile', but this doesn't change anything.
Any idea?
Many thanks.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Robert Osfieldrobert.osfi...@gmail.com a écrit :
Hi Sukender,
You explanation of what you are doing in your app is way too light
for
us to be able to guess what might be amiss. Are you running the
viewer? Is it just data preperation? I haven't got a clue.
Robert.
On Tue, Mar 22, 2011 at 5:42 PM, Sukendersuky0...@free.fr wrote:
Hi all,
Here's something strange:
- I create PageLODs that will load files on disk when needed
- I create Groups of PagedLODs
- I write those groups to disk (OSGB/T format). They thus contain
only few data (just nodes and paths where data is).
- I create a PagedLOD which loads this newly file on disk. The
group
is theorically unloaded after this.
When repeating this, my memory usage climbs very high... but the
groups should not be in memory... I wrote
osgDB::Options * options =
osgDB::Registry::instance()-getOptions();
options-setBuildKdTreesHint(osgDB::Options::DO_NOT_BUILD_KDTREES);
options-setObjectCacheHint(osgDB::Options::CACHE_NONE);
But this doesn't change anything.
And of course I finally run out of memory.
For info, small graphs behave normally in osgViewer (nodes load
when
approaching, memory usage rises, etc.).
Any idea?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org
Re: [osg-users] PagedLOD - Trying to understand climbing mem usage
Hi Maria,
Yes, I saw your post about this, and tried this kind of solution.
Unfortunately, the problem doesn't arise durung viewing but during data
preparation. The viewer isn't realized yet, and the database paging functions
are not being processed at this time. Registering to, or clearing the
DatabasePager have no effect.
Thanks anyway.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- María Ten mate...@gmail.com a écrit :
Hi Sukender,
The DatabasePager only update correctly the timestamp of expired
children if they are registered. After load a new PagedLOD with the
fileName, it is registered automatically, but the level 0 PagedLOD is
not registered because you created it manually. Since it is not
registered, the databasepager doesn't update the timestamp for the
expired children of this PagedLOD. So the children are not expired and
they remain in memory.
You have to call registerPagedLODs(rootNode)[1] after add the PagedLOD
to the scenegraph or call this method with the PagedLOD of level 0 as
parameter to force the DatabasePager to register it. For example:
osg::ref_ptrosg::PagedLOD paged( new osg::PagedLOD );
paged-addChild(new osg::Node);
paged-setFileName(1, pathTo3DFile);
paged-setRange(0, dist, FLT_MAX);
paged-setRange(1, 0, dist);
viewer.getDatabasePager()-registerPagedLODs(paged.get());
We have the same issue in our application and calling this method
works nice for us.
Cheers,
Maria.
[1] OSG Reference to registerPagedLODs method:
http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00163.html#2c20aad9d434a2a2d11b1c5d092d2e59
On Wed, Mar 23, 2011 at 11:54 AM, Laurens Voerman l.voer...@rug.nl
wrote:
Hi Sukender,
Your code can't cause the problem I suggested, so it must be something
else. I have no other suggestions to offer.
Laurens.
On 3/23/2011 11:12 AM, Sukender wrote:
Hi Laurens,
Thanks for the tip. But my function looks like:
osg::ref_ptrosg::PagedLOD paged( new osg::PagedLOD );
paged-addChild(new osg::Node);
paged-setFileName(1, pathTo3DFile);
paged-setRange(0, dist, FLT_MAX);
paged-setRange(1, 0, dist);
I create an empty child at index 0, viewable from 'dist' to FLT_MAX.
The second thing is not a child but a range+filename, viewable from 0
to 'dist.
This seems correct to me.
Thoughts?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Laurens Voerman l.voer...@rug.nl a écrit :
Hi Sukender,
Just a guess here,
when you say
Generate a PagedLOD, to load 'groupFile'
do you call PagedLOD::addChild(Node *child, ) ?
for the pageLOD will then hold the child in memory until
PagedLOD::removeExpiredChildren() is called. Normally this is done in
the frame loop (in updateSceneGraph()) but I think you're not in a
frame
loop (yet).
Laurens.
On 3/23/2011 10:19 AM, Sukender wrote:
Hi Robert,
Sorry for being too vague. It's a data preparation + viewer app,
but the problem arises during the data preparation. Some data sets do
not present the symptoms whereas some others do... Here is a more
detailed view of the problematic method, in pseudo-code:
void function(Group parent, const string path) {
If path is a directory
osg::ref_ptrosg::Group group(new osg::Group);
Foreach entry in the directory, do a recursive call:
function(group, entry).
write 'group' to disk, in 'groupFile' (somewhere out of the
current directory structure)
Generate a PagedLOD, to load 'groupFile' when below a given view
distance (using group-getBound())
Add that PagedLOD to 'parent'
unload the group (well, it's a local variable!)
else if it's a 3D file
Get the AABB of the 3D file (the file isn't loaded in memory)
Generate a PagedLOD, to load the 3D file when below a given view
distance (using AABB info)
Add that PagedLOD to 'parent'
}
This makes memory rise very high and very quickly on a given
dataset. This dataset is a hierarchical tree structure with at most
1000 3D files in each dir. What is strange is that the algorithm seems
quite straightforward. I'm just going crazy! I'm pretty sure there is
a stupid little thing around here that I didn't spot. Or is there some
OSG internal mechanism I didn't deactivate?
Tries:
- As I told, I wrote (before the method runs)
options = osgDB::Registry::instance()-getOptions();
options-setBuildKdTreesHint(osgDB::Options::DO_NOT_BUILD_KDTREES);
options-setObjectCacheHint(osgDB::Options::CACHE_NONE);
- I also tried adding databasePager.clear(); after writing the
'groupFile', but this doesn't change anything.
Any idea?
Many thanks.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Sukender,
You explanation of what you are doing in your app is way too light
for
us
Re: [osg-users] PagedLOD - Trying to understand climbing mem usage
Mmmm... if you got no more ideas, don't bother searching. This smells like
there's a memory leak around here (in my code, I guess). I'll keep you informed.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi Maria,
Yes, I saw your post about this, and tried this kind of solution.
Unfortunately, the problem doesn't arise durung viewing but during
data preparation. The viewer isn't realized yet, and the database
paging functions are not being processed at this time. Registering to,
or clearing the DatabasePager have no effect.
Thanks anyway.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- María Ten mate...@gmail.com a écrit :
Hi Sukender,
The DatabasePager only update correctly the timestamp of expired
children if they are registered. After load a new PagedLOD with the
fileName, it is registered automatically, but the level 0 PagedLOD
is
not registered because you created it manually. Since it is not
registered, the databasepager doesn't update the timestamp for the
expired children of this PagedLOD. So the children are not expired
and
they remain in memory.
You have to call registerPagedLODs(rootNode)[1] after add the
PagedLOD
to the scenegraph or call this method with the PagedLOD of level 0
as
parameter to force the DatabasePager to register it. For example:
osg::ref_ptrosg::PagedLOD paged( new osg::PagedLOD );
paged-addChild(new osg::Node);
paged-setFileName(1, pathTo3DFile);
paged-setRange(0, dist, FLT_MAX);
paged-setRange(1, 0, dist);
viewer.getDatabasePager()-registerPagedLODs(paged.get());
We have the same issue in our application and calling this method
works nice for us.
Cheers,
Maria.
[1] OSG Reference to registerPagedLODs method:
http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00163.html#2c20aad9d434a2a2d11b1c5d092d2e59
On Wed, Mar 23, 2011 at 11:54 AM, Laurens Voerman l.voer...@rug.nl
wrote:
Hi Sukender,
Your code can't cause the problem I suggested, so it must be
something
else. I have no other suggestions to offer.
Laurens.
On 3/23/2011 11:12 AM, Sukender wrote:
Hi Laurens,
Thanks for the tip. But my function looks like:
osg::ref_ptrosg::PagedLOD paged( new osg::PagedLOD );
paged-addChild(new osg::Node);
paged-setFileName(1, pathTo3DFile);
paged-setRange(0, dist, FLT_MAX);
paged-setRange(1, 0, dist);
I create an empty child at index 0, viewable from 'dist' to FLT_MAX.
The second thing is not a child but a range+filename, viewable from
0
to 'dist.
This seems correct to me.
Thoughts?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Laurens Voerman l.voer...@rug.nl a écrit :
Hi Sukender,
Just a guess here,
when you say
Generate a PagedLOD, to load 'groupFile'
do you call PagedLOD::addChild(Node *child, ) ?
for the pageLOD will then hold the child in memory until
PagedLOD::removeExpiredChildren() is called. Normally this is done
in
the frame loop (in updateSceneGraph()) but I think you're not in a
frame
loop (yet).
Laurens.
On 3/23/2011 10:19 AM, Sukender wrote:
Hi Robert,
Sorry for being too vague. It's a data preparation + viewer app,
but the problem arises during the data preparation. Some data sets
do
not present the symptoms whereas some others do... Here is a more
detailed view of the problematic method, in pseudo-code:
void function(Group parent, const string path) {
If path is a directory
osg::ref_ptrosg::Group group(new osg::Group);
Foreach entry in the directory, do a recursive call:
function(group, entry).
write 'group' to disk, in 'groupFile' (somewhere out of the
current directory structure)
Generate a PagedLOD, to load 'groupFile' when below a given view
distance (using group-getBound())
Add that PagedLOD to 'parent'
unload the group (well, it's a local variable!)
else if it's a 3D file
Get the AABB of the 3D file (the file isn't loaded in memory)
Generate a PagedLOD, to load the 3D file when below a given view
distance (using AABB info)
Add that PagedLOD to 'parent'
}
This makes memory rise very high and very quickly on a given
dataset. This dataset is a hierarchical tree structure with at most
1000 3D files in each dir. What is strange is that the algorithm
seems
quite straightforward. I'm just going crazy! I'm pretty sure there
is
a stupid little thing around here that I didn't spot. Or is there
some
OSG internal mechanism I didn't deactivate?
Tries:
- As I told, I wrote (before the method runs)
options = osgDB::Registry::instance()-getOptions();
options-setBuildKdTreesHint(osgDB::Options::DO_NOT_BUILD_KDTREES);
options-setObjectCacheHint(osgDB::Options::CACHE_NONE
Re: [osg-users] PagedLOD - Trying to understand climbing mem usage
self_hang
Downloaded a Windows leak detection utility trial (BoundsChecker, as Purify
doesn't work with my app).
Found a huge leak when using TinyXML++ (I naively thought reference counted
structures behaved as osg::ref_ptr and osg::Referenced).
/self_hang
Sorry for this.
*sigh*
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Mmmm... if you got no more ideas, don't bother searching. This smells
like there's a memory leak around here (in my code, I guess). I'll
keep you informed.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi Maria,
Yes, I saw your post about this, and tried this kind of solution.
Unfortunately, the problem doesn't arise durung viewing but during
data preparation. The viewer isn't realized yet, and the database
paging functions are not being processed at this time. Registering
to,
or clearing the DatabasePager have no effect.
Thanks anyway.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- María Ten mate...@gmail.com a écrit :
Hi Sukender,
The DatabasePager only update correctly the timestamp of expired
children if they are registered. After load a new PagedLOD with
the
fileName, it is registered automatically, but the level 0 PagedLOD
is
not registered because you created it manually. Since it is not
registered, the databasepager doesn't update the timestamp for the
expired children of this PagedLOD. So the children are not expired
and
they remain in memory.
You have to call registerPagedLODs(rootNode)[1] after add the
PagedLOD
to the scenegraph or call this method with the PagedLOD of level 0
as
parameter to force the DatabasePager to register it. For example:
osg::ref_ptrosg::PagedLOD paged( new osg::PagedLOD );
paged-addChild(new osg::Node);
paged-setFileName(1, pathTo3DFile);
paged-setRange(0, dist, FLT_MAX);
paged-setRange(1, 0, dist);
viewer.getDatabasePager()-registerPagedLODs(paged.get());
We have the same issue in our application and calling this method
works nice for us.
Cheers,
Maria.
[1] OSG Reference to registerPagedLODs method:
http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00163.html#2c20aad9d434a2a2d11b1c5d092d2e59
On Wed, Mar 23, 2011 at 11:54 AM, Laurens Voerman
l.voer...@rug.nl
wrote:
Hi Sukender,
Your code can't cause the problem I suggested, so it must be
something
else. I have no other suggestions to offer.
Laurens.
On 3/23/2011 11:12 AM, Sukender wrote:
Hi Laurens,
Thanks for the tip. But my function looks like:
osg::ref_ptrosg::PagedLOD paged( new osg::PagedLOD );
paged-addChild(new osg::Node);
paged-setFileName(1, pathTo3DFile);
paged-setRange(0, dist, FLT_MAX);
paged-setRange(1, 0, dist);
I create an empty child at index 0, viewable from 'dist' to
FLT_MAX.
The second thing is not a child but a range+filename, viewable
from
0
to 'dist.
This seems correct to me.
Thoughts?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Laurens Voerman l.voer...@rug.nl a écrit :
Hi Sukender,
Just a guess here,
when you say
Generate a PagedLOD, to load 'groupFile'
do you call PagedLOD::addChild(Node *child, ) ?
for the pageLOD will then hold the child in memory until
PagedLOD::removeExpiredChildren() is called. Normally this is done
in
the frame loop (in updateSceneGraph()) but I think you're not in a
frame
loop (yet).
Laurens.
On 3/23/2011 10:19 AM, Sukender wrote:
Hi Robert,
Sorry for being too vague. It's a data preparation + viewer app,
but the problem arises during the data preparation. Some data sets
do
not present the symptoms whereas some others do... Here is a more
detailed view of the problematic method, in pseudo-code:
void function(Group parent, const string path) {
If path is a directory
osg::ref_ptrosg::Group group(new osg::Group);
Foreach entry in the directory, do a recursive call:
function(group, entry).
write 'group' to disk, in 'groupFile' (somewhere out of the
current directory structure)
Generate a PagedLOD, to load 'groupFile' when below a given view
distance (using group-getBound())
Add that PagedLOD to 'parent'
unload the group (well, it's a local variable!)
else if it's a 3D file
Get the AABB of the 3D file (the file isn't loaded in memory)
Generate a PagedLOD, to load the 3D file when below a given view
distance (using AABB info)
Add that PagedLOD to 'parent'
}
This makes memory rise very high and very quickly
[osg-users] PagedLOD - Trying to understand climbing mem usage
Hi all, Here's something strange: - I create PageLODs that will load files on disk when needed - I create Groups of PagedLODs - I write those groups to disk (OSGB/T format). They thus contain only few data (just nodes and paths where data is). - I create a PagedLOD which loads this newly file on disk. The group is theorically unloaded after this. When repeating this, my memory usage climbs very high... but the groups should not be in memory... I wrote osgDB::Options * options = osgDB::Registry::instance()-getOptions(); options-setBuildKdTreesHint(osgDB::Options::DO_NOT_BUILD_KDTREES); options-setObjectCacheHint(osgDB::Options::CACHE_NONE); But this doesn't change anything. And of course I finally run out of memory. For info, small graphs behave normally in osgViewer (nodes load when approaching, memory usage rises, etc.). Any idea? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Textures Problem!!! Urgent!!
Hi Nectarios, Did you try updating the drivers? I already spotted strange things like this and it was a matter of drivers. And is there something special on your model, or is this simply a one-texture thing? Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Nectarios Pelekanos nectarios.peleka...@armes-tech.com a écrit : Hi, Can anyone help me on this!! The texture of the 3D object appears fine with an Nvidia card and fails with an ATI card. I have attached two images to see the problem. Thank you! Cheers, Nectarios -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37247#37247 Attachments: http://forum.openscenegraph.org//files/pot3_662.jpg http://forum.openscenegraph.org//files/untitled1_712.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Collada writer - Bad handling filenames with spaces?
Hi all, [This is slyghtly off-topic since related to libcollada-dom] When writing a Collada file to, say, ab c.dae, the written file is named ab%20c.dae. All other characters are correctly handled (I tried french accents, arabic, chinese, cyrilic...), but not the space. I found a suspicious line of code in daeLIBXMLPlugin.cpp, line 234, in daeLIBXMLPlugin::write(), which reads: writer = xmlNewTextWriterFilename(cdom::fixUriForLibxml(name.str()).c_str(), 0); Actually the name variable seems a good URI (with %20 encoding), but the xmlNewTextWriterFilename() function seems not to convert it correctly to a filesystem name. I use Collada-DOM v2.2 (DOM 1.4), under Win32. Anyone already found this? Linux users, can you confirm (or not) the same issue? Any idea? Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada writer - Bad handling filenames with spaces?
I cross-posted this to the Collada-dom bug tracker : https://sourceforge.net/tracker/?func=detailaid=3192134group_id=157838atid=805424 Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Hi all, [This is slyghtly off-topic since related to libcollada-dom] When writing a Collada file to, say, ab c.dae, the written file is named ab%20c.dae. All other characters are correctly handled (I tried french accents, arabic, chinese, cyrilic...), but not the space. I found a suspicious line of code in daeLIBXMLPlugin.cpp, line 234, in daeLIBXMLPlugin::write(), which reads: writer = xmlNewTextWriterFilename(cdom::fixUriForLibxml(name.str()).c_str(), 0); Actually the name variable seems a good URI (with %20 encoding), but the xmlNewTextWriterFilename() function seems not to convert it correctly to a filesystem name. I use Collada-DOM v2.2 (DOM 1.4), under Win32. Anyone already found this? Linux users, can you confirm (or not) the same issue? Any idea? Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FBX opacity map factor inverted?
Hi Michael, hi all, I spotted a strange line in fbxMaterialToOsgStateSet.cpp : result.opacityFactor = pFbxPhong-GetTransparencyFactor().Get(); Which says the opacity map (if present) will be affected an opacity. But what is retreived from FBX is the transparency, not the opacity. I guess the line should be: result.opacityFactor = 1.0 - pFbxPhong-GetTransparencyFactor().Get(); But I'm not 100% sure. However, this solves the display of some models I got :) Can anyone confirm (or not)? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] DDS - Changes about vertical flip
Hi Robert, hi all, [Topic moved from osg-sumbissions to osg-users] You're absolutely right about the need for clear rules. I don't know if there is a normative thing somewhare about DDS orientation (I didn't find any). Actually I just found that the tools and 3D engines I use have the exact opposite orientation. OSG was doing read direction 1, write direction 1, which was consistent, and tools were doind read/write direction 2, which was consistent too (note I did not use the terms normal or reverse orientation :) ). And of course, I have to make those DDS files be red/written both by my OSG application and those tools and engines. I could have put an option to make the DDS readerwriter use direction 2, but this raises two points : - How will I manage scene having a mix of images (images oriented differently) if I write them? They should be automatically flipped depending on their orientation, I guess. - This seems very strange that all those tools/engines (I mean those I use) use the same convention. Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, I've just reviewed these changes but find the logic a bit awkward (double negatives are never good) and potentially breaking of client applications - since the default for the write has changed. As a background to the flip issue, OpenGL's texture coordinates have the original at the bottom left which is consistent with the rest of the OpenGL coordinates systems. While traditional 2D applications and image format have the origin at the top left. I believe Direct3D followed the 2D traditions and has the origin at the top left. Now whether a dds files need to be flipped or not will depend up models they are associated with and the art path they have gone through. On write what you'll want to do will again depend upon what models it's associated with and what tools will be reading it. For instance one of the common usage write of dds file in the context of the OSG will be using VPB where the dds files are directly associated with the OSG, as things stand everything works as far as I know. This will have to remain the case without any external changes required. I think we need to nail down clear rules on when and when not to flip, and the use of the Origin needs to be done consistently as well i.e. not just when the flip is done. However, one problem is that there are dds files that have the origin in different places just by local convention of a particular tool, without any data about this stored in the dds file so it's all a bit messy when it comes to defaults. This would be a good topic to raise on osg-users. Robert. On Fri, Feb 11, 2011 at 9:17 AM, Sukender suky0...@free.fr wrote: Hi Robert, I guess I already sent you a modified DDS readerwriter, but it was never integrated... Or maybe I really really thought about sending it without doing it really :-D ? Anyway I've cleaned a few little things and it's now worth integrating, if you agree. - Vertically flipping DDS files upon reading (with the corresponding string option) now also sets the origin of the image (Image::setOrigin()) accordingly. - Writing DDS files now uses image's origin to automatically vertically flip if needed. This can be avoided using the ddsNoAutoFlipWrite option. Actually, it seems the vertical flip should be the standard reading way (at least for multiple 3rd-party software I use) but this would break code, so I didn't change the default behaviour (I only standardized the option name as you'll see). File BASE rev = 11941. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-submissions mailing list osg-submissi...@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org ___ osg-submissions mailing list osg-submissi...@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] IFC to OSG converter
Hi Peter, Nice work! Is this a ReaderWriter or a standalone converter? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Kilpatrick p...@scenescript.com a écrit : Hello, I am working on an IFC to OSG converter. There are some screenshots at www.scenescript.com . Regards, Peter Kilpatrick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Discussion: metadata readerwriters output
Hi Ulrich, Robert, and all,
Ulrich, your idea seem briliant. When I was talking about overwrit[ing]
existing userData I thought about direct pointer access. Of course, if you
move userData to private, and give accessors for backward compatibility, then
it's okay. That way, it would only break code of derivate classes which
directly access the protected member _userData ; and this seems a reasonable
change to me.
Finally, userData becomes a (multi)map of Referenced...? One point I would
discuss is the duplicates handling. I personally have nothing against having
duplicates (= multimap), and it may be useful to store, for instance, multiple
targets properties on a charcater, or multiple addresses on a building. But
this may be problematic for some usages. Another point to discuss is the kind
of container: some would need fast lookup (unordered containers), some not.
So what about the ability to choose that container? What do you think about:
- osg::Object contains a ref_ptrContainer (or ref_ptrReferenced)
- Container has templated derivates, such as ContainerMapT,
ContainerUnorderedMultimapT, ContainerVectorT (which may be
TemplateArray)... Those types are low-level, and may also be used elsewhere
in OSG.
- If not derived from STL clases, containers must have STL-like iterators in
order to make easy to templatize methods
- osg::Object has several methods to handle containers (set, get, delete,
replace)
- setProperty() would create a default container if none exists.
- Of course, get/setUserData() would still be there for backward compatibility,
as Ulrich proposed.
Thoughts? Ideas?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Ulrich Hertlein u.hertl...@sandbox.de a écrit :
On 4/02/11 3:21 , Sukender wrote:
Ulrich is right: you could move your data as a metadata. However I
guess that we should
not break existing code. (De)Serializers should NEVER overwrite
existing userData, they
should only be allowed to add metadata it userData points to a meta
container. So if
you already use userData, then you simply won't be able to add
metadata.
On this point is disagree: depending on the implementation of the
meta-data the user-data
can simply be stored alongside other meta-data.
The following is from my earlier attempts to implement something like
this:
include/osg/Object:
/**
* Sets a typed property by name.
* This convenience function will create a new PropertyT and store
* it under the given name.
*/
template typename T
inline void setProperty(const std::string name, const T value) {
if (!_properties.valid()) {
_properties = ref_ptrPropertyMap(new PropertyMap);
}
_properties-set(name, new PropertyT(value));
}
/**
* Gets a const typed property by name.
* Get property by name and cast it to const PropertyT.
* @return NULL when not found or not of the proper type, else the
const property.
*/
template typename T
inline const PropertyT* getProperty(const std::string name) const
{
return dynamic_castconst PropertyT*(getProperty(name));
}
/**
* Set user data.
* Data must be subclassed from Referenced to allow reference
counting.
* If your data isn't directly subclassed from Referenced, create an
adapter object
* which points to your own object and handles the memory addressing.
*/
inline void setUserData(Referenced* obj) {
setProperty(osg.data, obj);
}
/// Get user data.
inline Referenced* getUserData() {
return getProperty(osg.data);
}
/// Get const user data.
inline const Referenced* getUserData() const {
return getProperty(osg.data);
}
The way the user-data is serialized/deserialized doesn't need to
change.
Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Discussion: metadata readerwriters output
Hi Bob, Ulrich is right: you could move your data as a metadata. However I guess that we should not break existing code. (De)Serializers should NEVER overwrite existing userData, they should only be allowed to add metadata it userData points to a meta container. So if you already use userData, then you simply won't be able to add metadata. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Ulrich Hertlein u.hertl...@sandbox.de a écrit : On 3/02/11 3:47 , Bob Youmans wrote: What will the users do, who current utilize the userData in the node for their own specialized purposes? Is this going to break our models? I don't see a reason why user-data shouldn't be stored as another type of meta-data. So it should be fully compatible with user-data, both API-wise and serialization to/from disk. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Converting DrawArrays(TRIANGLE_STRIP) to DrawElements(TRIANGLES)
Hi Tim, I'll try to send an exemple. Can I send it to your address direclty? It's a very simple model with texture coordinates, created from the 3DS reader. I'll dump it as an OSG file beforehand. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Tim Moore timoor...@gmail.com a écrit : Hi Sukender, I'm not sure what you mean; I need to see an example. The IndexMeshVisitor doesn't work with BIND_PER_PRIMITIVE attributes and bails if it finds any. If the number of vertex coordinates doesn't equal the number of texture coordinates, that's a big bug. Normally the number of indices in the DrawElements result will be different from the number of vertex coordinates, etc. Tim On Mon, Jan 31, 2011 at 5:05 PM, Sukender suky0...@free.fr wrote: Hi Tim, Sorry to jump into that conversation, but I also had a bug related to IndexMeshVisitor: the output geometries do NOT have number of vertices == number of texcoords... Did I miss something? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Tim Moore timoor...@gmail.com a écrit : I've found that that problem happens because the attribute arrays are shared among several Geometry objects. The fix is simple, but I haven't submitted it yet because the results of INDEX_MESH are still not great on the sphere object, and I have a different idea for how to approve that. Tim On Mon, Jan 31, 2011 at 2:58 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Tim, That sucks. I'll take a look. OK, let me know what you find out. I was pretty surprised the optimizers would go out of bounds, as I've used them on a variety of models without problems (as I bet you have, and many others too). Thanks in advance, J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate mipmaps from arbitrary image
Hi Brad and Robert, Any news about having a mipmap generation thing directly into OSG? I cannot include code of VPB (LGPL) in my app (proprietary), and I do not think about linking to VPB just for mipmaps... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Hi Brad and Robert, Well thanks for the answers. I don't know if I'll wait for Robert's implementation or use VPB. Is there a plan to move this code from VPB to OSG? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Brad Christiansen brad.christian...@thalesgroup.com.au a écrit : Hi, The latest version of VPB has all the code you need to generate mip maps for an osg::Image / Texture. This code also allows you to select between NVTT (no context) or the current context based approach. The code is in TextureUtils: void compress(State state, Texture texture, Texture::InternalFormatMode compressedFormat, bool generateMipMap, bool resizeToPowerOfTwo, CompressionMethod method); void generateMipMap(State state, Texture texture, bool resizeToPowerOfTwo, CompressionMethod method); While this does have a cuple of VPB dependancies, these would be very easy to remove. Cheers, Brad -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33518#33518 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture atlas and shared state?
Hi JS, I'm not sure of the problem, but there may be a problem with IVE writer. Try: - saving to an OSG file to see the differences - checking if there are no optimizer that change statesets Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit : Hi all, On my quest to reduce the amount of statesets and draw calls in my graph, I've started building texture atlases with the osgUtil::Optimizer::TextureAtlasVisitor. Now, when I build the texture atlas(es) for a given model, I then save a .ive file of that model which includes the textures, and thus the atlas(es) too. So far so good. Unfortunately, I'm seeing an issue in our simulator that looks like OSG is using the same texture atlas for any model that uses texture atlases (i.e. the first texture atlas that was loaded is applied to any model that uses texture atlases). Indeed, if I dump the scene to a .osg file and examine it, I can see that there's one state set with a texture called atlas_0.rgb, and then all other objects have Use Texture2D_20 in their state sets, where Texture2D_20 is that atlas. I had noticed that osgUtil::Optimizer::TextureAtlasVisitor named its atlases atlas_0.ext, atlas_1.ext etc., but I thought that since I was saving to .ive there would be no problem, it would use the texture from the file when loading and all would be fine. What's weird is that I can't reproduce the problem in plain osgViewer - the textures are not mixed up if I load the .ive files (with atlases) all together in osgviewer. So it must be something in our app. To try and eliminate this, I disabled our use of the osgDB::SharedStateManager and our ReadFileCallback that would cache loaded files and share them. So now, all files should be loaded from disk and state should not be shared between files. But still this problem happens. I debugged into the ive loader's loading of images, and it seems to be loading them directly from the bits of the loaded file, so I don't see how the textures could be shared... Did anyone ever have this kind of problem? Where else could I look to find the problem? Will OSG or the ive loader do any sharing of loaded resources by itself? I guess I could do a kludge where I would traverse the graph just before saving, and add a model-dependent prefix to the filename of any image named atlas_*.* ... But since this works out of the box in osgviewer, I'd like to find out why it doesn't work in our app and fix it correctly... :-) Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate mipmaps from arbitrary image
Hi Robert, I indeed missed the news. Many thanks. However I don't understand one point: must I have NVTT to build mipmaps in my app (I do not use VBP, only OSG), or will the ImageProcessor default to another implementation if not found? Or is the NVTT source code directly integrated in OSG? (or am I wrong somewhere? ;) ) Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Tue, Feb 1, 2011 at 10:57 AM, Sukender suky0...@free.fr wrote: Any news about having a mipmap generation thing directly into OSG? I cannot include code of VPB (LGPL) in my app (proprietary), and I do not think about linking to VPB just for mipmaps... You obviously missed the news about GLU integration into the core OSG that provides minmap generation without the need for a graphics context, and a new NVTT plugin that provides mipmap generation and texture compression without the need for graphics context. The NVTT plugin is accessed via the osgDB::ImageProcessor interface class. You can get the ImageProcessor from the osgDB::Registry via: osgDB::ImageProcessor* ip = osgDB::Registry::instance()-getImageProcessor(); This will automatically load the NVTT if it's available. VPB now uses this NVTT support, so doesn't required NVTT as an external dependency, if you want NVTT support then you simply build the OSG with it and VPB will pick the ImageProcessor implementation automatically. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate mipmaps from arbitrary image
Hi Robert, Oh. Well, what I actually was loking for was the convenience method! And about compression, I already created some code using the libsquish directly... So if I add NVTT when building OSG, I'll be able to generate mipmaps (as the convenience method would do) AND do compression? Maybe I'll switch to NVTT (= drop libsquish as it is included) if so. Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Tue, Feb 1, 2011 at 12:06 PM, Sukender suky0...@free.fr wrote: I indeed missed the news. Many thanks. However I don't understand one point: must I have NVTT to build mipmaps in my app (I do not use VBP, only OSG), or will the ImageProcessor default to another implementation if not found? Or is the NVTT source code directly integrated in OSG? (or am I wrong somewhere? ;) ) If all you want to do is generate mipmaps than you can use the OSG's internal glu functions. It's been my intention to add a convenience method into osg::Image to generate the mipmaps use the glu functions, but I haven't had a chance to do this yet. All that needs to be do is to use the custom gluScaleImage entry point to create the individual mipmaps and assign them to the osg::Image. If you want texture compression then you'll need the NVTT plugin and use ImageProcessor. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate mipmaps from arbitrary image
Hi Robert, Oh. Well, what I actually was loking for was the convenience method! You could always write it and submit it ;-) It'd only be 10 to 20 lines of code, I'd tackle it right away if I didn't have dozens of other TODO items on my list. Well, same thing for me! This is why I didn't wrote it... And about compression, I already created some code using the libsquish directly... So if I add NVTT when building OSG, I'll be able to generate mipmaps (as the convenience method would do) AND do compression? Maybe I'll switch to NVTT (= drop libsquish as it is included) if so. I briefly experiment with libsquish in VPB but didn't adopt it it would require users to obtain a separate license for the S3TC patents. NVTT comes with a license grant for the S3TC patents, there are still few restrictions so it's worth reading up about it in the NVTT docs. FYI, NVTT uses libsquish. Yes, I knew NVTT included libsquish. However I did not find anything related to patents or such in the docs. It'd also be possible to write an ImageProcessor implementation that just uses libsquish, but as this doesn't change the patent situation it probably isn't worth the effort writing until these parents expire, or when software patents are declare void by governments/the courts. Agreed. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Discussion: metadata readerwriters output
Hi Gordon and Paul, Yes, you're right to say the a scene graph is not designed to handled something else than the scene. However, yes, this is a philosophical question... what is a scene, then? I belive a scene is not only what is displayed, but includes metadata too. Usages are many. For instane, you may compute an intersection using the scenegraph, and grab information on the elements you picked. Or you may dynamically change scene's properties (say LOD view distance) depending on some data somewhere... Of course, I certainly do not want to put something too intrusive, or (worse) something which would cause a performance loss. So what? Well I think OSG should provide some tools to ease the management of metadata. Not necessary something deeply tied with the graph, but maybe utilities. But even if I agree with the fact metadata should be handled in a separate structure to avoid polluting the main graph, I do not fint this solution satisfactory. What if I delete a node? References to the node are invalidated, and child-number indices are also invalidated. I would thus need a mechanism to make sure everything is coherent. Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Gordon Tomlinson gtomlin...@overwatch.textron.com a écrit : I have to agree with Paul, the Scene graph is just that. To renders data as fast and efficiently as possible OLD Performer handled some this by providing separate graphs for data and other information (while it was not close to perfect it did allow the clean separation that Paul is talking about and I agree with Gordon Tomlinson 3D Technology System Engineering Consultant Overwatch® An Operating Unit of Textron Systems __ WARNING: Documents that can be viewed, printed or retrieved from this E-Mail may contain technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq,) or the Export Administration Act of 1979, as amended, Title 50, U.S.C., App. 2401 et seq. and which may not be exported, released or disclosed to non-U.S. persons (i.e. persons who are not U.S. citizens or lawful permanent residents [green card holders]) inside or outside the United States, without first obtaining an export license. Violations of these export laws are subject to severe civil, criminal and administrative penalties. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Monday, January 31, 2011 11:18 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Discussion: metadata readerwriters output On 1/31/2011 9:00 AM, Sukender wrote: Hi Paul, Thanks for this explanation about identifying nodes. Actually we also implemented a node identification using child index... However I did not spot metadata related classes in osgWorks. Well, ok, I just had a very quick overview... Can you tell me where to look at? Thanks. Once you have a mechanism for identifying nodes that is not address-based and therefore works from one app invocation to the next, there is no need for any OSG-specific metadata classes. Such metadata can be stored outside the scene graph. However, if you want to associate metadata with the scene graph, you just use UserData. Perhaps we have a philosophical difference. In my opinion, a scene graph should not be turned into a general purpose data structure. The scene graph should be tuned and optimized for operations on spatial data such as rendering and intersection testing. Rather, the app should associate subgraphs of the scene graph with its internal app data structure, as visual representations of app-specific entities. Using this approach, an app can use the NodePathUtils in osgWorks to identify the relevant nodes to reference from its internal data structure. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Converting DrawArrays(TRIANGLE_STRIP) to DrawElements(TRIANGLES)
Fixed :) I'm sumbitting the change. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Tim Moore timoor...@gmail.com a écrit : On Tue, Feb 1, 2011 at 11:39 AM, Sukender suky0...@free.fr wrote: Hi Tim, I'll try to send an exemple. Can I send it to your address direclty? Sure. Tim It's a very simple model with texture coordinates, created from the 3DS reader. I'll dump it as an OSG file beforehand. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Tim Moore timoor...@gmail.com a écrit : Hi Sukender, I'm not sure what you mean; I need to see an example. The IndexMeshVisitor doesn't work with BIND_PER_PRIMITIVE attributes and bails if it finds any. If the number of vertex coordinates doesn't equal the number of texture coordinates, that's a big bug. Normally the number of indices in the DrawElements result will be different from the number of vertex coordinates, etc. Tim On Mon, Jan 31, 2011 at 5:05 PM, Sukender suky0...@free.fr wrote: Hi Tim, Sorry to jump into that conversation, but I also had a bug related to IndexMeshVisitor: the output geometries do NOT have number of vertices == number of texcoords... Did I miss something? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Tim Moore timoor...@gmail.com a écrit : I've found that that problem happens because the attribute arrays are shared among several Geometry objects. The fix is simple, but I haven't submitted it yet because the results of INDEX_MESH are still not great on the sphere object, and I have a different idea for how to approve that. Tim On Mon, Jan 31, 2011 at 2:58 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Tim, That sucks. I'll take a look. OK, let me know what you find out. I was pretty surprised the optimizers would go out of bounds, as I've used them on a variety of models without problems (as I bet you have, and many others too). Thanks in advance, J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Discussion: metadata readerwriters output
Hi Peter, Robert, and all Thank you for your ideas. I think the metadata container put in userData is the simplest way. And I fully agree there should be some minimal base classes to support it in core OSG. So... Who's for that solution? If so, any idea about implementation details, or requirements? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : Some kind of user data hooks are necessary, since the user is always going to need a way to map the results of operations like IntersectVisitor back to the application domain. The benefit of adding a baseline metadata system as standard (as opposed to the current do-what-ever-you-want situation with UserData) is for it to be supported and interoperable by non-core but broadly used libraries and plugins such as osgDB reader/writers that have a narrow interface (e.g. osgDB::readNode()). On further consideration, I think that storing metadata separately from nodes may cause more problems than it solves unless there are additional management elements. Path-based methods are brittle under changes to the scene graph and approaches that refer to nodes by memory address fail in corner cases like clone operations. A more robust solution might be to have every osg::Node assigned a platform-independent unique id or turn that around and have each metadata entry have a unique id to which osg::Node can refer. Scene graph serialization already has to assign unique ids to support shared nodes. However the simplest solution I can think of would be to provide a standard osgUtil::Metadata object designed to go into the existing UserData field, which would provide a property-oriented data structure as I described in my earlier email. Serialization reader/writers would be enhanced to read/write osgUtil::Metadata from the UserData field if present. For applications that already use UserData for something else, or don't need metadata, there would be no change to existing behavior. On 2/1/2011 10:20 AM, Sukender wrote: Hi Gordon and Paul, Yes, you're right to say the a scene graph is not designed to handled something else than the scene. However, yes, this is a philosophical question... what is a scene, then? I belive a scene is not only what is displayed, but includes metadata too. Usages are many. For instane, you may compute an intersection using the scenegraph, and grab information on the elements you picked. Or you may dynamically change scene's properties (say LOD view distance) depending on some data somewhere... Of course, I certainly do not want to put something too intrusive, or (worse) something which would cause a performance loss. So what? Well I think OSG should provide some tools to ease the management of metadata. Not necessary something deeply tied with the graph, but maybe utilities. But even if I agree with the fact metadata should be handled in a separate structure to avoid polluting the main graph, I do not fint this solution satisfactory. What if I delete a node? References to the node are invalidated, and child-number indices are also invalidated. I would thus need a mechanism to make sure everything is coherent. Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Gordon Tomlinson gtomlin...@overwatch.textron.com a écrit : I have to agree with Paul, the Scene graph is just that. To renders data as fast and efficiently as possible OLD Performer handled some this by providing separate graphs for data and other information (while it was not close to perfect it did allow the clean separation that Paul is talking about and I agree with -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Discussion: metadata readerwriters output
Hi Paul, Thanks for this explanation about identifying nodes. Actually we also implemented a node identification using child index... However I did not spot metadata related classes in osgWorks. Well, ok, I just had a very quick overview... Can you tell me where to look at? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Paul Martz pma...@skew-matrix.com a écrit : If a specific node in a scene graph can be reliably identified, application data can be stored separately from the scene graph. Unfortunately, OSG's mechanism for identifying a node (the NodePath) is address-based, making it unsuitable for this task, as addresses change from one app invocation to the next. osgWorks has a solution for this. It has a set of NodePathUtils that identify nodes based on child index, node name, and class name, along with conversion utilities to switch between NodePaths and the string representation. Because the string isn't address-based, these utilities allow an app to identify a specific node between application invocations. Application-specific data can be stored saved to a database keyed by the NodePath's string representation, then restored later, for example. Just wanted to mention this, as the osgWorks metadata solution is already available and requires no changes to core OSG. -Paul On 1/28/2011 2:54 AM, Sukender wrote: Hi Robert, hi (SELECT name FROM OSG_USERS WHERE nameRobert Osfield;), ** Context ** I spotted the DAE plugin is able to return some values to the calling program by writing in the plugin data (options-getPluginData()). But when writing, this plugin data is... const! This thus requires an ugly and unsafe const_cast (or an even uglier C-style cast). In other words: readers should not return any value except the scene graph itself, or generally speaking predefined return values. I also think that using void* is just a maintanability pain, with high risks of writing unallocated memory parts, and such. ** Topic ** More generally, it is hard to store and pass not predifined variables between main program and plugins, or between OSG itself and the main program (I mean adding some type-safe user values to the graph). This makes me think about something I discussed a bit before: the ability to handle metadata in OSG (post named Suggestion: Add components in nodes (aggregation)). To sum up the discussion, it was roughly said that it's on user side, and use userData!. However, the meta system I implemented for my app is now quite used and stable. I want it to be open sourced so that partners using OSG also have access to metadata, and I propose this to be integrated. But I don't wan't to simply copy-paste it into a submission; I'd like to have a real reflexion around it, to make it useable for all. After all, more and more file formats handle these metas, so why not OSG, as long as it does not disturb existing features? ** Ideas ** So... starting the reflexion, I have a few ideas: 1. What is a meta? A meta is a name/typed value pair. Possible implementation is to have a base class (with the name, say MetaBase), and several derived (Metaint, deriving from MetaBase, and then Metastd::string...). There could be as many meta types as you wish, but only a few standard ones should be defined in OSG (int, double, string...). 2. How to store them (the container)? 2.1. Have a simple, yet easy and stable way: a basic container (vector/list). Duplicate meta names should be handled on user's side if necessary. 2.2. Have a name-value map. Implementation may be a bit less flexible, but this ensures faster lookup (is this necessary?), and name unicity (is this necessary?). 2.3. Other ideas: multimap, unordered_map, etc. 2.4. Have a user-defined container. That way, user may ask for a simple vector, or a very complex DataBase-type container. As my colleague told me: usages can be too different to tell beforehand the container type. This is surely a good idea, but how to implement it? Work with iterators? Have a container base class? Use templates somewhere? Help! FYI: my implementation uses a vector container (having generally less than 10-20 metas in a container), with the MetaBase / Metasomething idea. 3. Where to store them? - Maybe there is a need to store them just in another variable, alongside userData. This is one of my needs, but I still can use userData as I do, even if that's not as clean as having directly a container in osg::Object. Note: to avoid burdening osg::Object too much, this could be a ref_ptr to a container. - Maybe there is a need for ReaderWriters, as I told at the begining of my email? I guess so, but this does not solve the constness problem if put in the Options structure. Or maybe we should provide ReaderWriter a non const container to play with? 4. How to serialize/deserialize them? I
Re: [osg-users] Converting DrawArrays(TRIANGLE_STRIP) to DrawElements(TRIANGLES)
Hi Tim, Sorry to jump into that conversation, but I also had a bug related to IndexMeshVisitor: the output geometries do NOT have number of vertices == number of texcoords... Did I miss something? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Tim Moore timoor...@gmail.com a écrit : I've found that that problem happens because the attribute arrays are shared among several Geometry objects. The fix is simple, but I haven't submitted it yet because the results of INDEX_MESH are still not great on the sphere object, and I have a different idea for how to approve that. Tim On Mon, Jan 31, 2011 at 2:58 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Tim, That sucks. I'll take a look. OK, let me know what you find out. I was pretty surprised the optimizers would go out of bounds, as I've used them on a variety of models without problems (as I bet you have, and many others too). Thanks in advance, J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Discussion: metadata readerwriters output
Hi Robert, hi (SELECT name FROM OSG_USERS WHERE nameRobert Osfield;), ** Context ** I spotted the DAE plugin is able to return some values to the calling program by writing in the plugin data (options-getPluginData()). But when writing, this plugin data is... const! This thus requires an ugly and unsafe const_cast (or an even uglier C-style cast). In other words: readers should not return any value except the scene graph itself, or generally speaking predefined return values. I also think that using void* is just a maintanability pain, with high risks of writing unallocated memory parts, and such. ** Topic ** More generally, it is hard to store and pass not predifined variables between main program and plugins, or between OSG itself and the main program (I mean adding some type-safe user values to the graph). This makes me think about something I discussed a bit before: the ability to handle metadata in OSG (post named Suggestion: Add components in nodes (aggregation)). To sum up the discussion, it was roughly said that it's on user side, and use userData!. However, the meta system I implemented for my app is now quite used and stable. I want it to be open sourced so that partners using OSG also have access to metadata, and I propose this to be integrated. But I don't wan't to simply copy-paste it into a submission; I'd like to have a real reflexion around it, to make it useable for all. After all, more and more file formats handle these metas, so why not OSG, as long as it does not disturb existing features? ** Ideas ** So... starting the reflexion, I have a few ideas: 1. What is a meta? A meta is a name/typed value pair. Possible implementation is to have a base class (with the name, say MetaBase), and several derived (Metaint, deriving from MetaBase, and then Metastd::string...). There could be as many meta types as you wish, but only a few standard ones should be defined in OSG (int, double, string...). 2. How to store them (the container)? 2.1. Have a simple, yet easy and stable way: a basic container (vector/list). Duplicate meta names should be handled on user's side if necessary. 2.2. Have a name-value map. Implementation may be a bit less flexible, but this ensures faster lookup (is this necessary?), and name unicity (is this necessary?). 2.3. Other ideas: multimap, unordered_map, etc. 2.4. Have a user-defined container. That way, user may ask for a simple vector, or a very complex DataBase-type container. As my colleague told me: usages can be too different to tell beforehand the container type. This is surely a good idea, but how to implement it? Work with iterators? Have a container base class? Use templates somewhere? Help! FYI: my implementation uses a vector container (having generally less than 10-20 metas in a container), with the MetaBase / Metasomething idea. 3. Where to store them? - Maybe there is a need to store them just in another variable, alongside userData. This is one of my needs, but I still can use userData as I do, even if that's not as clean as having directly a container in osg::Object. Note: to avoid burdening osg::Object too much, this could be a ref_ptr to a container. - Maybe there is a need for ReaderWriters, as I told at the begining of my email? I guess so, but this does not solve the constness problem if put in the Options structure. Or maybe we should provide ReaderWriter a non const container to play with? 4. How to serialize/deserialize them? I personnally have straightforward toString()/fromString() methods to convert back and forth. This is then used by my own plugins to read/write those metas. This is certainly not the best implementation, but surely the simplest. Another idea would be make plugins (or other code) directly read values and (de)serialize them as they want; however, I suggest to keep the toString()/fromString() methods in order to handle unknown types. Many thanks to those who have read entirety this text. More thanks for your thougts/ideas/remarks/insults(?)/comments/whatever. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Discussion: metadata readerwriters output
Hi Peter, Robert, all Thanks for your ideas, Peter. I really appreciate the proposal of having values in a separate structure with weak references. But is this a singleton? If so, how would you handle the case where you have to process things between two models (say you want to load two files and merge/process them anyhow)? Robert, what is your opinion on Peter's idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : I have run into the same problem trying to get metadata from the OpenFlight loader. In my application I handled the attributes problem by using the Description field on osg::Node, which stores an arbitrary list of strings and unlike UserData can be serialized by various osgDB plugins. I encoded attributes in Key=Value form, with only the most trivial parsing of splitting on the '=' and any further type coercion handled on the user side. This works for my needs but is obviously unsuitable for storing large or complex data. For a thorough solution to this problem, my suggestion would be: a) Define a few primitive types, like integer, float and string. Define a couple of container types, vector and map. Containers can contain other containers. b) Serializerizers translate the generic structure to/from other formats such as binary, XML, JSON, prettyprint etc as appropriate for target format. c) Consider maintaining metadata in a table separately from the scene graph. So instead of adding a getMetadata() to osg::Node, there might be an osgDB::Metadata object with a method getMetadataForNode(osg::Node*). This avoids burdening the scene graph with additional fields. The osgDB::Metadata would hold weak references so it doesn't interfere with the existing object lifecycle of nodes. This also has the advantage of being separate from the osg core and not requiring as much buy-in from Robert if he doesn't like it :-) Cheers, Pete On 1/28/2011 4:54 AM, Sukender wrote: Hi Robert, hi (SELECT name FROM OSG_USERS WHERE nameRobert Osfield;), ** Context ** I spotted the DAE plugin is able to return some values to the calling program by writing in the plugin data (options-getPluginData()). But when writing, this plugin data is... const! This thus requires an ugly and unsafe const_cast (or an even uglier C-style cast). In other words: readers should not return any value except the scene graph itself, or generally speaking predefined return values. I also think that using void* is just a maintanability pain, with high risks of writing unallocated memory parts, and such. ** Topic ** More generally, it is hard to store and pass not predifined variables between main program and plugins, or between OSG itself and the main program (I mean adding some type-safe user values to the graph). This makes me think about something I discussed a bit before: the ability to handle metadata in OSG (post named Suggestion: Add components in nodes (aggregation)). To sum up the discussion, it was roughly said that it's on user side, and use userData!. However, the meta system I implemented for my app is now quite used and stable. I want it to be open sourced so that partners using OSG also have access to metadata, and I propose this to be integrated. But I don't wan't to simply copy-paste it into a submission; I'd like to have a real reflexion around it, to make it useable for all. After all, more and more file formats handle these metas, so why not OSG, as long as it does not disturb existing features? ** Ideas ** So... starting the reflexion, I have a few ideas: 1. What is a meta? A meta is a name/typed value pair. Possible implementation is to have a base class (with the name, say MetaBase), and several derived (Metaint, deriving from MetaBase, and then Metastd::string...). There could be as many meta types as you wish, but only a few standard ones should be defined in OSG (int, double, string...). 2. How to store them (the container)? 2.1. Have a simple, yet easy and stable way: a basic container (vector/list). Duplicate meta names should be handled on user's side if necessary. 2.2. Have a name-value map. Implementation may be a bit less flexible, but this ensures faster lookup (is this necessary?), and name unicity (is this necessary?). 2.3. Other ideas: multimap, unordered_map, etc. 2.4. Have a user-defined container. That way, user may ask for a simple vector, or a very complex DataBase-type container. As my colleague told me: usages can be too different to tell beforehand the container type. This is surely a good idea, but how to implement it? Work with iterators? Have a container base class? Use templates somewhere? Help! FYI: my implementation uses a vector container (having generally less than 10-20 metas in a container), with the MetaBase / Metasomething idea. 3. Where to store
[osg-users] FBX writer - Strange behaviour (images lost)
Hi all FBX writer users (kind of narrow subset of osg-users, hey?), I'm experiencing a very strange behaviour when writing FBX files: they have no texturation at all. Plugin options seem correct, and writing FBX materials seem correct. However, the SDK manager object indicates (when debugging) several errors, including: - a file not found immediately after the manager is created (what is missing? A DLL module???) - several unexpected errors of the same type during the process - and a message saying the FBX file is corrupt at the end of the writing! I cannot find out which event made the texturation broken. My code? The FBX plugin? Anyway, if anyone could give me a hint, this would be very nice. Config: Win32, MSVC9, FBX SDK 2011.3.1 (latest). Thank you. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Incomplete TIFF plugin (tiled images)
Hi all, Thanks to the TIFF error ouput (See corresponding submission, a few minutes ago), I found that current TIFF plugin does not read tiled images properly. Has anyone worked on this? I found several functions like TIFFIsTiled(), TIFFReadTile()/TIFFReadRGBATile(), and tileContigRoutine/tileSeparateRoutine typedefs. However, I lack information about tiling to modify the plugin accordingly. Can anyone tell me anything interesting about it? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] libtiff update
Hi all, I tried to update libtiff to 4.0.0beta6 (I thought my tiled images issue it was a matter of version - See corresponding post), but unfortunately the libtiff strangely fails to make a==a be true at some point (SeekOK) on Win32 MSVC9 (test uses a 64 bit integer comparison inside a macro - works well only if you truncate to an int). Did anyone try to update the libtiff for osgPlugin TIFF? Thank you. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi all, As said in my post (a few minutes ago), it sounds like we do not all agree on what is a primitive! OpenGL says a primitive can be a strip/fan ( http://www.opengl.org/wiki/Primitives ). However, I agree it sounds very strange to have same behaviour for BIND_PER_PRIMITIVE and BIND_PER_PRIMITIVE_SET. Should we introduce BIND_PER_ELEMENT or such? Should we rename the BIND_PER_PRIMITIVE and BIND_PER_PRIMITIVE_SET? Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Wojciech Lewandowski lewandow...@ai.com.pl a écrit : Hi Robert, Jason, I am lazy guy, and I agree with both of you, its only neccessary to make it backward compatibile ;-) However, for purely academic reasons I will respond to Jason. But don't treat my post as call for revolution. Its just my opinion how PER_VERTEX, PER_PRIMITIVE, PER_PRIMITIVE_SET should be resolved for Triangle strips. But, I will state it again, if it was differently done before, then lets keep it as it used to be. Now lets get to our academic discussion: In Jason's post BIND_PER_PRIMITIVE does the same as BIND_PER_PRIMITIVE_SET for Triangle strips. Note that if this was correct behaviour then TriangleStrips with BIND_PER_PRIMITIVE binding could use fast paths. Instead, IMHO thats how these bindings should be translated to glBegin/glEnd OpenGL code: // Color BIND_PER_VERTEX : N vertices, N colors glBegin(GL_TRIANGLE_STRIP); glColor4f( ... ); // set color for each vertex glVertex3f( ... ); glColor4f( ... ); glVertex3f( ... ); ... glColor4f( ... ); glVertex3f( ... ); glEnd(); // Color BIND_PER_PRIMITIVE : N vertices, N-2 colors glBegin(GL_TRIANGLE_STRIP); glVertex3f( ... ); // two verts without colors glVertex3f( ... ); glColor4f( ... ); // starting from third vertex, we pass color for each provoking vertex of triangle glVertex3f( ... ); glColor4f( ... ); glVertex3f( ... ); ... glColor4f( ... ); glVertex3f( ... ); glEnd(); // Color BIND_PER_PRIMITIVE_SET : N vertices, 1 color glColor4f( ... ); // set color once glBegin(GL_TRIANGLE_STRIP); glVertex3f( ... ); // no need for colors glVertex3f( ... ); ... glVertex3f( ... ); glEnd(); With above interpretation, only PER_PRIMITIVE binding cannot be done with fast paths DrawArrays. So general recommendation to avoid BIND_PER_PRIMITIVE as slow path trigger, still makes sense. Second: I would not treat Performer as ultimate reference for resolving all doubts. Performer did not offer PER_PRIMITIVE_SET binding and also had additional PFGS_FLAT_LINESTRIPS, PFGS_FLAT_TRISTRIPS in addition to classic PFGS_LINESTRIPS, PFGS_TRISTRIPS we have in OSG. I actually wonder what the colors would look like here. Did you actually run this code? My guess would be that the final vertex is green, but the final triangle would blend from red to green across its surface, because its two other vertices were red (as specified in the code). I could be wrong (I haven't run the code myself), but that's what I would expect. Even if you consider each triangle in the strip a different primitive, you still couldn't get a set of completely red triangles, followed by a completely green triangle, which is what the OP is looking for. I ran it and yes you can. I guess, thats what PFGS_FLAT_TRISTRIPS was doing in Performer. With flat shading (activated in example), one triangle is red and second is green. With smooth shading second triangle is colored wtih red - green gradient. Last argument is actually a postulate for OSG clarity. We have BIND_PER_PRIMITIVE_SET flag. Shouldn't this flag be rather used for the situation where we want to one normal / one color etc for all triangles in tristrip ? If I understand you correctly, then yes. BIND_PER_PRIMITIVE in the case of triangle strips should mean the same normal/color for each entire triangle strip (that's how Performer used to treat it as well). If I remember correctly, the OP was looking to get different normals for each triangle in the strip (to produce a faceted appearance, I think). I don't believe this is possible even in pure OpenGL. The only way to do it is to use distinct triangles for primitives. Well... what you write sounds like you don't agree with me, because I postulate that that BIND_PER_PRIMITIVE should differ from BIND_PER_PRIMITIVE_SET and BIND_PER_VERTEX. And yes I will say that again, its possible to make faceted apperance with triangle strips in OpenGL. Thats was my point in my first post and thats what this short example I posted was doing. Btw good point about GL_TRIANGLES instead of GL_TRIANGLE ;-) Highest Regards ;-) Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Wojtek,
Allright. So what about changing the terms we use? Say BIND_PER_SHAPE /
BIND_PER_PRIMITIVE, or BIND_PER_ELEMENT / BIND_PER_PRIMITIVE?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Wojciech Lewandowski lewandow...@ai.com.pl a écrit :
Hi, Sukender,
I think we fully agree both on whats a 'Primitive' and binding
interpretations. I actually like your interpretation of primitive
term.
Primitive is always a Triangle and Triangles, TriangleFans and
TriangleStrips are just a methods of passing vertices. But I avoided
using
word Primitive because I had the feeling that it can have slightly
different
semantics in OpenGL docs and different in Performer docs and different
in
OSG.
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:22 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi all,
Interesting discusssion. I didn't guess that it wouyld bring so much
comments!
Well this cannot be a regression as I'm implementing it! I just need
to make
it work the old style way.
However, I would expect that a primitive is one of {point, line,
triangle,
quad}, even id OpenGL says a strip is also a primitive (is there a
naming
issue there? Should we have something like elements, primitive and
primitive set???). So, for me, PER_PRIMITIVE is a binding for them,
and
PER_PRIMITIVE_SET is a binding for a bunch of them :
TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN : primitive = one triangle /
primitive set = all triangles
QUADS, QUAD_STRIP : primitive = one quad / primitive set = all quads
Once again, that's only my point of view.
Actually, OpenGL can do this binding (even if it's slow), so why not
supporting it if it's not that difficult? Should we name it
differently?
Thank you all for your comments and ideas.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Jason Daly jd...@ist.ucf.edu a écrit :
On 1/8/2011 6:19 AM, Robert Osfield wrote:
Hi All,
Perhaps we should be asking the question what was the behavior
prior
to the refactor to I did for GL3/OpenGLES support. Sukender did
your
Geometry work previously? Is this a regression or just a
behaviour
that you weren't expecting?
Good question!
---
Somehow I missed Wojtek's post, so I'll reply to that here:
glBegin(GL_TRIANGLE)/glEnd() code with 2 triangles and one
normal.
It will
be correct OpenGL code. Would you say that two triangles
correspond
to one
OSG primitive or two OSG primitves in this case ? And if you do
not
pass
normal before second triangle, OpenGL will use last normal passed
(ie the
one from first triangle):
glBegin(GL_TRIANGLE);
glNormal3f(...);
glVertex3f(...); //1
glVertex3f(...); //2
glVertex3f(...); //3
// no normal and its no error !
glVertex3f(...); //4
glVertex3f(...); //5
glVertex3f(...); //6
glEnd();
It's two primitives. Yes, you can use the same normal for two
separate
triangles, but that doesn't mean it's not two primitives. Actually
your
code is slightly incorrect, the glBegin() line should read:
glBegin(GL_TRIANGLES);
I'm not pointing this out just to be pedantic. It's evidence to
support
my position that it's actually two primitives (i.e.: two triangles)
in
that case :-)
In the same way OpenGL assumes that last passed normal is used
for
the
triangle in triangle strip. Triangle Srip is just another method
of
passing
vertices to OpenGL and each triangle may have its own unique
normals/colors.
If you don't agree, just do a reverse test: see if below would
render both
triangles with the same color or different colors. They will
differ, and
this is also correct OpenGL code:
glShadeModel( GL_FLAT );
glBegin(GL_TRIANGLE_STRIP);
glColor4f( 1, 0, 0, 1 ); // RED
glVertex3f(0, 0, 0);
glVertex3f(0, 1, 0);
glVertex3f(1, 0, 0);
glColor4f( 0, 1, 0, 1 ); // GREEN
glVertex3f(1, 1, 0);
glEnd();
Yes, I mentioned that in my previous post. It doesn't take away
from
the fact that the triangle strip is considered a single primitive.
I actually wonder what the colors would look like here. Did you
actually run this code? My guess would be that the final vertex is
green, but the final triangle would blend from red to green across
its
surface, because its two other vertices were red (as specified in
the
code). I could be wrong (I haven't run the code myself), but
that's
what I would expect. Even if you consider each triangle in the
strip
a
different primitive, you still couldn't get a set of completely
red
triangles, followed by a completely green triangle, which is what
the
OP
is looking for.
Last argument is actually a postulate for OSG clarity. We have
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Wojtek,
Well, just to avoid confusion with the term used for OpenGL primitives :)
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Wojciech Lewandowski lewandow...@ai.com.pl a écrit :
Hi Sukender,
What for ? If we agreed on Primitive meaning a single Triangle from
TriangleStrip then we don't need to change the enums. Current binding
smenatics are valid:
PER_PRIMIITIVE means per triangle
PER_PRIMITIVE_SET means per triangle strip
and of course
PER_VERTEX means per vertex
OVERALL means the same attrib (normal/color) for all primitive sets in
geometry.
Why change that ?
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:59 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Wojtek,
Allright. So what about changing the terms we use? Say BIND_PER_SHAPE
/
BIND_PER_PRIMITIVE, or BIND_PER_ELEMENT / BIND_PER_PRIMITIVE?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Wojciech Lewandowski lewandow...@ai.com.pl a écrit :
Hi, Sukender,
I think we fully agree both on whats a 'Primitive' and binding
interpretations. I actually like your interpretation of primitive
term.
Primitive is always a Triangle and Triangles, TriangleFans and
TriangleStrips are just a methods of passing vertices. But I avoided
using
word Primitive because I had the feeling that it can have slightly
different
semantics in OpenGL docs and different in Performer docs and
different
in
OSG.
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:22 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi all,
Interesting discusssion. I didn't guess that it wouyld bring so much
comments!
Well this cannot be a regression as I'm implementing it! I just need
to make
it work the old style way.
However, I would expect that a primitive is one of {point, line,
triangle,
quad}, even id OpenGL says a strip is also a primitive (is there a
naming
issue there? Should we have something like elements, primitive
and
primitive set???). So, for me, PER_PRIMITIVE is a binding for
them,
and
PER_PRIMITIVE_SET is a binding for a bunch of them :
TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN : primitive = one triangle /
primitive set = all triangles
QUADS, QUAD_STRIP : primitive = one quad / primitive set = all quads
Once again, that's only my point of view.
Actually, OpenGL can do this binding (even if it's slow), so why not
supporting it if it's not that difficult? Should we name it
differently?
Thank you all for your comments and ideas.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Jason Daly jd...@ist.ucf.edu a écrit :
On 1/8/2011 6:19 AM, Robert Osfield wrote:
Hi All,
Perhaps we should be asking the question what was the behavior
prior
to the refactor to I did for GL3/OpenGLES support. Sukender
did
your
Geometry work previously? Is this a regression or just a
behaviour
that you weren't expecting?
Good question!
---
Somehow I missed Wojtek's post, so I'll reply to that here:
glBegin(GL_TRIANGLE)/glEnd() code with 2 triangles and one
normal.
It will
be correct OpenGL code. Would you say that two triangles
correspond
to one
OSG primitive or two OSG primitves in this case ? And if you do
not
pass
normal before second triangle, OpenGL will use last normal
passed
(ie the
one from first triangle):
glBegin(GL_TRIANGLE);
glNormal3f(...);
glVertex3f(...); //1
glVertex3f(...); //2
glVertex3f(...); //3
// no normal and its no error !
glVertex3f(...); //4
glVertex3f(...); //5
glVertex3f(...); //6
glEnd();
It's two primitives. Yes, you can use the same normal for two
separate
triangles, but that doesn't mean it's not two primitives.
Actually
your
code is slightly incorrect, the glBegin() line should read:
glBegin(GL_TRIANGLES);
I'm not pointing this out just to be pedantic. It's evidence to
support
my position that it's actually two primitives (i.e.: two
triangles)
in
that case :-)
In the same way OpenGL assumes that last passed normal is used
for
the
triangle in triangle strip. Triangle Srip is just another
method
of
passing
vertices to OpenGL and each triangle may have its own unique
normals/colors.
If you don't agree, just do a reverse test: see if below would
render both
triangles with the same color or different colors. They will
differ, and
this is also correct OpenGL code:
glShadeModel( GL_FLAT );
glBegin(GL_TRIANGLE_STRIP);
glColor4f( 1, 0, 0, 1 ); // RED
glVertex3f(0, 0, 0
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Wojtek and Frederic,
Indeed, it seems OpenGL natively reads per vertex normals, by checking the
current normal value (given with glNormal()). And when looking at
glShadeModel(), it says which vertex normal is used when doing GL_FLAT
lighting (roughly: the last vertex of the triangle/quad/polygon).
Conclusion (IMHO): BIND_PER_PRIMITIVE should do it per triangle/quad/polygon :)
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Wojciech Lewandowski lewandow...@ai.com.pl a écrit :
Hi Frederic,
it is my understanding that OpenGL can only do BIND_PER_VERTEX
natively.
There is no such thing as a face normal or color. There is only
linear
interpolation between values at vertices. So when you share vertex
data
in a primitive, you can only share also normal, color and other
attributes.
Interpolation is done when you have GL_SMOOTH shade model. If shade
model is
GL_FLAT you can have per face binding. See OpenGL help on glShadeModel
function.
Wojtek
- Sukender a écrit :
Hi all,
Interesting discusssion. I didn't guess that it wouyld bring so much
comments!
Well this cannot be a regression as I'm implementing it! I just need
to make it work the old style way.
However, I would expect that a primitive is one of {point, line,
triangle, quad}, even id OpenGL says a strip is also a primitive (is
there a naming issue there? Should we have something like
elements,
primitive and primitive set???). So, for me, PER_PRIMITIVE is a
binding for them, and PER_PRIMITIVE_SET is a binding for a bunch
of
them :
TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN : primitive = one triangle /
primitive set = all triangles
QUADS, QUAD_STRIP : primitive = one quad / primitive set = all quads
Once again, that's only my point of view.
Actually, OpenGL can do this binding (even if it's slow), so why not
supporting it if it's not that difficult? Should we name it
differently?
Thank you all for your comments and ideas.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Jason Daly jd...@ist.ucf.edu a écrit :
On 1/8/2011 6:19 AM, Robert Osfield wrote:
Hi All,
Perhaps we should be asking the question what was the behavior
prior
to the refactor to I did for GL3/OpenGLES support. Sukender
did
your
Geometry work previously? Is this a regression or just a
behaviour
that you weren't expecting?
Good question!
---
Somehow I missed Wojtek's post, so I'll reply to that here:
glBegin(GL_TRIANGLE)/glEnd() code with 2 triangles and one
normal.
It will
be correct OpenGL code. Would you say that two triangles
correspond
to one
OSG primitive or two OSG primitves in this case ? And if you do
not
pass
normal before second triangle, OpenGL will use last normal
passed
(ie the
one from first triangle):
glBegin(GL_TRIANGLE);
glNormal3f(...);
glVertex3f(...); //1
glVertex3f(...); //2
glVertex3f(...); //3
// no normal and its no error !
glVertex3f(...); //4
glVertex3f(...); //5
glVertex3f(...); //6
glEnd();
It's two primitives. Yes, you can use the same normal for two
separate
triangles, but that doesn't mean it's not two primitives.
Actually
your
code is slightly incorrect, the glBegin() line should read:
glBegin(GL_TRIANGLES);
I'm not pointing this out just to be pedantic. It's evidence to
support
my position that it's actually two primitives (i.e.: two
triangles)
in
that case :-)
In the same way OpenGL assumes that last passed normal is used
for
the
triangle in triangle strip. Triangle Srip is just another
method
of
passing
vertices to OpenGL and each triangle may have its own unique
normals/colors.
If you don't agree, just do a reverse test: see if below would
render both
triangles with the same color or different colors. They will
differ, and
this is also correct OpenGL code:
glShadeModel( GL_FLAT );
glBegin(GL_TRIANGLE_STRIP);
glColor4f( 1, 0, 0, 1 ); // RED
glVertex3f(0, 0, 0);
glVertex3f(0, 1, 0);
glVertex3f(1, 0, 0);
glColor4f( 0, 1, 0, 1 ); // GREEN
glVertex3f(1, 1, 0);
glEnd();
Yes, I mentioned that in my previous post. It doesn't take away
from
the fact that the triangle strip is considered a single primitive.
I actually wonder what the colors would look like here. Did you
actually run this code? My guess would be that the final vertex
is
green, but the final triangle would blend from red to green across
its
surface, because its two other vertices were red (as specified in
the
code). I could be wrong (I haven't run the code myself), but
that's
what I would expect. Even if you consider each triangle
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Yes, Jason. This is why I proposed to have a BIND_PER_ELEMENT, which would do per triangle/quad (since OpenGL says a strip is a primitive). Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jason Daly jd...@ist.ucf.edu a écrit : On 01/10/2011 03:46 AM, Wojciech Lewandowski wrote: Hi, Sukender, I think we fully agree both on whats a 'Primitive' and binding interpretations. I don't think we agree at all... man glBegin NAME glBegin, glEnd - delimit the vertices of a primitive or a group of like primitives C SPECIFICATION void glBegin( GLenum mode ) PARAMETERS mode Specifies the primitive or primitives that will be created from vertices presented between glBegin and the subsequent glEnd. Ten symbolic constants are accepted:GL_POINTS, GL_LINES, GL_LINE_STRIP, GL_LINE_LOOP, GL_TRIANGLES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, GL_QUADS, GL_QUAD_STRIP, and GL_POLYGON. glDrawArrays also refers to the mode parameter as specifying what kind of primitives to render. From what I've read (I just went and did a cursory check), the OpenGL spec agrees with what the man pages. I really don't think we should be redefining what a primitive is, we should stick with OpenGL's terms. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi all, Yeeek... think I'm gonna BIND_PER_VERTEX+GL_FLAT finally! ;p Joking apart, I agree with the fact it's deprecated and should just stick with OSG 2.8 bahaviour. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jason Daly jd...@ist.ucf.edu a écrit : On 01/10/2011 11:26 AM, Robert Osfield wrote: Hi Guys, For reference on this discussion, non of BIND_PER_PRIMITIVE or the proposed BIND_PER_ELEMENT are supported by modern OpenGL/OpenGL ES, the old BIND_PER_PRIMITIVE is very much deprecated and only kept around for backwards compatibility. Given even BIND_PER_PRIMTIIVE is deprecated there is absolutely no way I'm about to merge another enum and implementation that is not supported by OpenGL and forces the OSG to use slow paths and will forever have been screaming on the list DO NOT USE THIS FEATURE as your performance will be crap Perhaps I should just remove BIND_PER_PRIMITIVE and vertex indices and provide automatic conversion for all crappy osg::Geometry? This is certainly something I'm planning to do for OSG-3.2 as the current situation is if a feature is there it will be used and abused. For OSG-3.0 the only change we should make for the BIND_PER_PRIMITIVE implementation is to make sure it's consistent with 2.8.x as it's sole purpose is for backwards compatibility to allows users to easily migrate to 3.x. I guess that's the end of the academic discussion ;-) I'm 100% behind this idea. It's always possible to get whatever binding behavior you want by manipulating the vertex arrays to provide per-vertex data. The only real reason to have the other bindings these days is for convenience. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Robert all,
I also got a problem with BIND_PER_PRIMITIVE (yes, I know I should not use it!
;) ). When having TRIANGLE_STRIP, with normals per primitive, I got one normal
per triangle strip, whereas OpenGL seem to say I should have one normal per
triangle. Am I wrong?
The geometry looks like :
Geometry {
// blah blah blah...
PrimitiveSets 3
{
DrawArrays TRIANGLE_STRIP 0 219
DrawArrays TRIANGLE_STRIP 219 19
DrawArrays TRIANGLE_STRIP 238 15
}
VertexArray Vec3Array 253
{
blah blah blah...
}
NormalBinding PER_PRIMITIVE
NormalArray UniqueID Vec3Array_1 Vec3Array 247
{
0 0 1
0 1 0
1 0 1
... and all other normals, which are not used at all.
}
}
In this case the first DrawArrays uses normal 0, the second uses normal 1...
I looked into ArrayDispatchers, but I was unable to find something usefult to
me.
Help, please?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote:
I confirmed that the bug persists in today's SVN trunk. In the
example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there is
different behaviour.
I've also isolated the two geometries that use BIND_PER_PRIMITIVE and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and then
re-test.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi again,
About my problem with triangle strips (see below), I found something strange in
Geometry::drawImplementation() :
unsigned int primLength;
switch(mode)
{
case(GL_POINTS):primLength=1; break;
case(GL_LINES): primLength=2; break;
case(GL_TRIANGLES): primLength=3; break;
case(GL_QUADS): primLength=4; break;
default:primLength=0; break; // compute later when
=0.
}
// draw primitives by the more flexible slow path,
// sending OpenGL glBegin/glVertex.../glEnd().
switch(primitiveset-getType())
{
case(PrimitiveSet::DrawArraysPrimitiveType):
{
if (primLength==0) primLength=primitiveset-getNumIndices();
If i understand well, it means that when having GL_TRIANGLE_STRIP, then
primLength is set to the length of the strip, not the length of a triangle.
Shouldn't the switch statement be extended with other types ?
case(GL_TRIANGLE_FAN):
case(GL_TRIANGLE_STRIP):
case(GL_TRIANGLES): primLength=3; break;
Or is 'primLength' used for another purpose ?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi Robert all,
I also got a problem with BIND_PER_PRIMITIVE (yes, I know I should not
use it! ;) ). When having TRIANGLE_STRIP, with normals per primitive,
I got one normal per triangle strip, whereas OpenGL seem to say I
should have one normal per triangle. Am I wrong?
The geometry looks like :
Geometry {
// blah blah blah...
PrimitiveSets 3
{
DrawArrays TRIANGLE_STRIP 0 219
DrawArrays TRIANGLE_STRIP 219 19
DrawArrays TRIANGLE_STRIP 238 15
}
VertexArray Vec3Array 253
{
blah blah blah...
}
NormalBinding PER_PRIMITIVE
NormalArray UniqueID Vec3Array_1 Vec3Array 247
{
0 0 1
0 1 0
1 0 1
... and all other normals, which are not used at all.
}
}
In this case the first DrawArrays uses normal 0, the second uses
normal 1...
I looked into ArrayDispatchers, but I was unable to find something
usefult to me.
Help, please?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote:
I confirmed that the bug persists in today's SVN trunk. In the
example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there is
different behaviour.
I've also isolated the two geometries that use BIND_PER_PRIMITIVE
and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and then
re-test.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Thanks for your answer Robert.
About sources, I do not have (yet) an official source, but only a large bunch
of forums/discussions saying the same thing. I'd like to find a more reliable
source of info before starting.
And of course I can do it, but unfortunately not soon (= a few days).
= If anyone knows about the subject, please confirm (or not) there should be
one normal per triangle when having triangle strip (or triangle fan / quad
strip) + bind per primitive. Thanks.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Sukender,
Do you an online reference to confirm the interpretation of per
primitive binding when using triangles and quad strips?
It does sound like your suggestion of adding GL_TRIANGLE_STRIP and
FAN
to the switch statement setting the primitive length might be
appropriate. Could you implement this and test it out?
Robert.
On Fri, Jan 7, 2011 at 2:16 PM, Sukender suky0...@free.fr wrote:
Hi again,
About my problem with triangle strips (see below), I found something
strange in Geometry::drawImplementation() :
unsigned int primLength;
switch(mode)
{
case(GL_POINTS): primLength=1; break;
case(GL_LINES): primLength=2; break;
case(GL_TRIANGLES): primLength=3; break;
case(GL_QUADS): primLength=4; break;
default: primLength=0; break; // compute
later when =0.
}
// draw primitives by the more flexible slow path,
// sending OpenGL glBegin/glVertex.../glEnd().
switch(primitiveset-getType())
{
case(PrimitiveSet::DrawArraysPrimitiveType):
{
if (primLength==0)
primLength=primitiveset-getNumIndices();
If i understand well, it means that when having GL_TRIANGLE_STRIP,
then primLength is set to the length of the strip, not the length of a
triangle. Shouldn't the switch statement be extended with other types
?
case(GL_TRIANGLE_FAN):
case(GL_TRIANGLE_STRIP):
case(GL_TRIANGLES): primLength=3; break;
Or is 'primLength' used for another purpose ?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi Robert all,
I also got a problem with BIND_PER_PRIMITIVE (yes, I know I should
not
use it! ;) ). When having TRIANGLE_STRIP, with normals per
primitive,
I got one normal per triangle strip, whereas OpenGL seem to say I
should have one normal per triangle. Am I wrong?
The geometry looks like :
Geometry {
// blah blah blah...
PrimitiveSets 3
{
DrawArrays TRIANGLE_STRIP 0 219
DrawArrays TRIANGLE_STRIP 219 19
DrawArrays TRIANGLE_STRIP 238 15
}
VertexArray Vec3Array 253
{
blah blah blah...
}
NormalBinding PER_PRIMITIVE
NormalArray UniqueID Vec3Array_1 Vec3Array 247
{
0 0 1
0 1 0
1 0 1
... and all other normals, which are not used at all.
}
}
In this case the first DrawArrays uses normal 0, the second uses
normal 1...
I looked into ArrayDispatchers, but I was unable to find something
usefult to me.
Help, please?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com
wrote:
I confirmed that the bug persists in today's SVN trunk. In
the
example
already supplied the overall color is not applied when normals
are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there
is
different behaviour.
I've also isolated the two geometries that use
BIND_PER_PRIMITIVE
and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour
from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and
then
re-test.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users
Re: [osg-users] [build] 3rd party libs and VS 2010
Hi Brad, hi all, Files available at http://sukender.free.fr/pvle/files/vc10/ (All are Windows x64 MSVC10 with Windows SDK 7.1, both release and debug). Help yourself! Warning: these are dumb copies of my directories (less some files, such as .obj, .pdb, ...). If you plan to make a nice repository of binaries, please tell. Important notes: - If you feel some have to be compiled with options (dynamic, static, another version, etc.), please ask. - I recently found that some libs changed their output directory. I thus updated my CMake finders. Please find my finders in the PVLE SVN trunk, at https://pvle.svn.sourceforge.net/svnroot/pvle/trunk/CMakeModules/ , or browse at http://pvle.svn.sourceforge.net/viewvc/pvle/trunk/CMakeModules/ Versions are: - boost_1_44_0 (dynamic only) - curl-7.21.1 without SSL (dynamic only, with zlib) - freealut-1.1.0 (both static and dynamic) - freeglut-2.6.0 (dynamic only) - freetype-2.4.2 (static only, didn't found dynamic) - jpeg-8b (static only) - png 1.4.3 (dynamic only) - ODE 0.11.1 (dynamic only, single precision only) - ogg SVN rev. 17535 (dynamic only) - OpenAL-Soft GIT rev. 4f81bce800c91bf0676cdff4267ce474d88ebf5a (dynamic only) - osgAudio SVN rev. 67 (dynamic only) - tiff-3.9.4 (static only) - vorbis SVN rev. 17535 (dynamic only) - zlib 1.2.5 (dynamic only) Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Allright. I'll try doing it ASAP (tomorrow I guess). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Brad Christiansen brad.christian...@thalesgroup.com.au a écrit : Hi, I certainly am. I am not doing a 64bit build at the moment but it will save me (and others) some time compiling them. If you can get them to me I will package them up and post a link on the osg-wiki. I am not sure I will get it done in the next week or as I am off on holidays on Saturday for a week, but I will upload them once I get back if I run out of time. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender Sent: Wednesday, 10 November 2010 6:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [build] 3rd party libs and VS 2010 Hi Brad, I got some dependencies for VC10 64bits (WinSDK 7.1): - curl-7.21.1 without SSL - freetype-2.4.2 - jpeg-8b - lpng143 - zlib And some others: - Boost 1.44 - freealut-1.1.0 - libsquish - ode-0.11.1 - ogg, vorbis - OpenAL-Soft Interested? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Brad Christiansen brad.christian...@thalesgroup.com.au a écrit : Hi, Ideally this shouldn't be necessary as the cmake find modules should be able to find what is needed once you have set the 3rdParty dir in cmake. I think I have not structured my dependencies correctly for the all to be found. It is on my to-do list to clean up the dependencies I have published, and if necessary modify the 'find module' cmake files so they are all automatically detected, but this task never seems to rise to the top to the list : ) If anyone has built 64 bit dependencies using VS2010 I am happy to package them up and make them available too. It is also on my to-do list to publish 64bti binaries but that is another task that never quite seems to get done. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Joel Graff Sent: Saturday, 6 November 2010 8:41 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [build] 3rd party libs and VS 2010 Just as a follow-up (esp. for others who aren't greatly familiar with cmake), I discovered that most of my problems getting the various plugins to show up in the generated VS project were solved by clicking the Advanced checkbox in the upper right of the cmake gui. This exposes a whole bunch more variables for referencing libraries, not the least of which are the Freetype libraries. I set the directory paths / lib locations and viola! freetype compiles! Hope it helps save someone else a week of work trying to get OSG to compile... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33554#33554 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org DISCLAIMER:--- This e-mail transmission and any documents, files and previous
Re: [osg-users] [build] 3rd party libs and VS 2010
Hi Brad, I got some dependencies for VC10 64bits (WinSDK 7.1): - curl-7.21.1 without SSL - freetype-2.4.2 - jpeg-8b - lpng143 - zlib And some others: - Boost 1.44 - freealut-1.1.0 - libsquish - ode-0.11.1 - ogg, vorbis - OpenAL-Soft Interested? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Brad Christiansen brad.christian...@thalesgroup.com.au a écrit : Hi, Ideally this shouldn't be necessary as the cmake find modules should be able to find what is needed once you have set the 3rdParty dir in cmake. I think I have not structured my dependencies correctly for the all to be found. It is on my to-do list to clean up the dependencies I have published, and if necessary modify the 'find module' cmake files so they are all automatically detected, but this task never seems to rise to the top to the list : ) If anyone has built 64 bit dependencies using VS2010 I am happy to package them up and make them available too. It is also on my to-do list to publish 64bti binaries but that is another task that never quite seems to get done. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Joel Graff Sent: Saturday, 6 November 2010 8:41 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [build] 3rd party libs and VS 2010 Just as a follow-up (esp. for others who aren't greatly familiar with cmake), I discovered that most of my problems getting the various plugins to show up in the generated VS project were solved by clicking the Advanced checkbox in the upper right of the cmake gui. This exposes a whole bunch more variables for referencing libraries, not the least of which are the Freetype libraries. I set the directory paths / lib locations and viola! freetype compiles! Hope it helps save someone else a week of work trying to get OSG to compile... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33554#33554 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] 3rd party libs and VS 2010
Allright. I'll try doing it ASAP (tomorrow I guess). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Brad Christiansen brad.christian...@thalesgroup.com.au a écrit : Hi, I certainly am. I am not doing a 64bit build at the moment but it will save me (and others) some time compiling them. If you can get them to me I will package them up and post a link on the osg-wiki. I am not sure I will get it done in the next week or as I am off on holidays on Saturday for a week, but I will upload them once I get back if I run out of time. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender Sent: Wednesday, 10 November 2010 6:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [build] 3rd party libs and VS 2010 Hi Brad, I got some dependencies for VC10 64bits (WinSDK 7.1): - curl-7.21.1 without SSL - freetype-2.4.2 - jpeg-8b - lpng143 - zlib And some others: - Boost 1.44 - freealut-1.1.0 - libsquish - ode-0.11.1 - ogg, vorbis - OpenAL-Soft Interested? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Brad Christiansen brad.christian...@thalesgroup.com.au a écrit : Hi, Ideally this shouldn't be necessary as the cmake find modules should be able to find what is needed once you have set the 3rdParty dir in cmake. I think I have not structured my dependencies correctly for the all to be found. It is on my to-do list to clean up the dependencies I have published, and if necessary modify the 'find module' cmake files so they are all automatically detected, but this task never seems to rise to the top to the list : ) If anyone has built 64 bit dependencies using VS2010 I am happy to package them up and make them available too. It is also on my to-do list to publish 64bti binaries but that is another task that never quite seems to get done. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Joel Graff Sent: Saturday, 6 November 2010 8:41 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [build] 3rd party libs and VS 2010 Just as a follow-up (esp. for others who aren't greatly familiar with cmake), I discovered that most of my problems getting the various plugins to show up in the generated VS project were solved by clicking the Advanced checkbox in the upper right of the cmake gui. This exposes a whole bunch more variables for referencing libraries, not the least of which are the Freetype libraries. I set the directory paths / lib locations and viola! freetype compiles! Hope it helps save someone else a week of work trying to get OSG to compile... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33554#33554 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org DISCLAIMER
Re: [osg-users] Generate mipmaps from arbitrary image
Hi Brad and Robert, Well thanks for the answers. I don't know if I'll wait for Robert's implementation or use VPB. Is there a plan to move this code from VPB to OSG? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Brad Christiansen brad.christian...@thalesgroup.com.au a écrit : Hi, The latest version of VPB has all the code you need to generate mip maps for an osg::Image / Texture. This code also allows you to select between NVTT (no context) or the current context based approach. The code is in TextureUtils: void compress(State state, Texture texture, Texture::InternalFormatMode compressedFormat, bool generateMipMap, bool resizeToPowerOfTwo, CompressionMethod method); void generateMipMap(State state, Texture texture, bool resizeToPowerOfTwo, CompressionMethod method); While this does have a cuple of VPB dependancies, these would be very easy to remove. Cheers, Brad -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33518#33518 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Generate mipmaps from arbitrary image
Hi all, I need to generate mipmaps from an osg::Image (a 2D image actually, which may be S3TC-DXTC compressed or not), and I have no OpenGL context. I just want my image to have mipmaps. Do you know anything that may help me? - Something to get a context without having to realize something, or with an invisible window? - Something to allocate mipmap memory, compute mipmaps, and store them in the osg::Image? I guess osg::gluBuild2DMipmaps() is the key, but it needs a context and process does not appear to be straightforward to me. Thanks. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate mipmaps from arbitrary image
Hi Robert, Having a Image::buildMipmaps() would be nice to me. I'd handle compressed textures by myself. Please let me know via osg-users... And having NVTT as an extension could be nice too. What about the KTX/ETC format ( http://www.khronos.org/opengles/sdk/tools/KTX/ )? Are there plans to integrate Khronos' format using libktx? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, My plan is to add a Image::buildMipmaps() functions that will use the new local gluScaleImage function that no longer requires a graphics context. However, this function won't support compressed textures as GLU has never support texture compression, and our integration of GLU parts into the OSG hasn't magically changed this. I am also planning to integrate NVidiaTextureTools as an OSG plugin/extension which will be able to compliment the GLU functions and add support for compressed texture formats. This will however require the NVTT as external dependency. I may be able to get on to these tasks next week. Robert. On Thu, Nov 4, 2010 at 11:47 AM, Sukender suky0...@free.fr wrote: Hi all, I need to generate mipmaps from an osg::Image (a 2D image actually, which may be S3TC-DXTC compressed or not), and I have no OpenGL context. I just want my image to have mipmaps. Do you know anything that may help me? - Something to get a context without having to realize something, or with an invisible window? - Something to allocate mipmap memory, compute mipmaps, and store them in the osg::Image? I guess osg::gluBuild2DMipmaps() is the key, but it needs a context and process does not appear to be straightforward to me. Thanks. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Crash with new StatsHandler?
Hi all, [Config: MSVC9, 32 bits, latest OSG trunk] I got a strange crash when launching osgViewer. StatsHandler allocates a new Camera, and the Camera allocates a StateSet... and this crashes. Stack trace looks like: std::mapstd::pairenum osg::StateAttribute::Type,unsigned int,std::pairosg::ref_ptrosg::StateAttribute,unsigned int,std::lessstd::pairenum osg::StateAttribute::Type,unsigned int ,std::allocatorstd::pairstd::pairenum osg::StateAttribute::Type,unsigned int const ,std::pairosg::ref_ptrosg::StateAttribute,unsigned int ::mapstd::pairenum osg::StateAttribute::Type,unsigned int,std::pairosg::ref_ptrosg::StateAttribute,unsigned int,std::lessstd::pairenum osg::StateAttribute::Type,unsigned int ,std::allocatorstd::pairstd::pairenum osg::StateAttribute::Type,unsigned int const ,std::pairosg::ref_ptrosg::StateAttribute,unsigned int () Ligne 104 C++ osg::StateSet::StateSet() Ligne 89 + 0x7a octets C++ osg::Camera::Camera() Ligne 40 + 0x22 octets C++ osgViewer::StatsHandler::StatsHandler() Ligne 51 + 0x25 octets C++ main(int argc=2, char * * argv=0x00f49808) Ligne 119 + 0x30 octets C++ Any idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBX Up axis bug
Hi Thomas,
As discussed earlier, readerwriters should, by default, not change anything
about the orientation simply because there is no standard one. However, a
readerwriter may provide options to read/write/modify this. As far as I know,
the FBX format itself doesn't define its own orientation.
Hope this helps.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Thomas Hogarth thomas.hoga...@googlemail.com a écrit :
Hi all
Just a little heads up for anyone using fbx plugin with fbx sdk
2011.2. I found a bug with the up axis. When exporting from 3ds max
the axis are stored as
x=0
y=1
z=2
But for some reason the fbx sdk 2011.2 sets the eUpVector enum in
kfbxaxissystem.h to the following
enum eUpVector {
XAxis = 1,
YAxis = 2,
ZAxis = 3
};
changing this to
enum eUpVector {
XAxis = 0,
YAxis = 1,
ZAxis = 2
};
fixed our problems
Hope someone finds this useful
Tom
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New osgText library - Questions
Thanks Robert. I'll have a look after regenerate/clean/make everything... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : On Wed, Oct 27, 2010 at 1:21 PM, Sukender suky0...@free.fr wrote: Alright then... but why didn't my app compile, then? I can't answer this. Are there known regressions? I don't know of any present regressions, if there are lets us know. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image cache and manually release
Hi Patrice, You could try things in osgDB::Registry - use expiry time: addEntryToObjectCache(..., timestamp) removeExpiredObjectsInCache() - Or remove all things in cache: clearObjectCache() - Or replace the prvious one: addEntryToObjectCache(filename, [NULL or a dummy object]). Not sure NULL will work as expected here (to be tested). Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Patrice Defond patrice.desfo...@rsacosmos.com a écrit : Hi, I would like to release an image, but there is a cache whose keep my image in memory. Even if i put my ref_ptros::Image to NULL, the image is always in memory. Do you know how i can manually destruct my object but without desactivate Image Cache ? Thank you! Cheers, Patrice -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33229#33229 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image cache and manually release
Hi Patrice, Got two ideas : 1. addEntryToObjectCache(filename, new MyDummyEmptyObject()); 2. addEntryToObjectCache(, 0.0001); removeExpiredObjectsInCache();(if and only if this does not interract negatively with the rest of your app). I personnally prefer the first one. If it still doesn't work, try using a debugger and trace when the image gets referenced. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Patrice Defond patrice.desfo...@rsacosmos.com a écrit : Thank for your help Sukender. I can't use the methods removeExpiredObjectsInCache and clearObjectCache because the rest of my application need the cache. It is very specific for a module : it loads big images. So i test addEntryToObjectCache. - With NULL in object : OSG make an error (Error file does not contain an osg::Object) - if i call the function with a timestamp to 0 or 0.001 ... but my object is not release. Do you have more ideas ? Cheers, Patrice -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33237#33237 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New osgText library - Questions
Alright then... but why didn't my app compile, then? Are there known regressions? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, Right now I'd recommend just sticking with osgText::Text and osgText::Text3D as TextNode isn't feature complete yet. I will be maintaining Text and Text3D for 3.0 to retain backwards compatibility. Robert. On Tue, Oct 26, 2010 at 3:04 PM, Sukender suky0...@free.fr wrote: Hi all, When updating to latest trunk, I faced the refactoring of osgText. Of course my app has been updated to fit this change, but I don't know how to get the old behaviour back. Can someone assist me? How must I transform these when I got a TextNode*? 1. setAlignment(osgText::Text::LEFT_TOP) 2. setColor() (I guess it's Stateset Material Diffuse) 3. setBackdropType() / setBackdropColor() / setColorGradientMode() / setColorGradientCorners()... Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [OT] I18N libraries
Thanks Fred. That sounds interesting. I would love to have a CMakeLists.txt with gettext, but as gettext is purely GNU I guess that's not possible... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Frederic Bouvier fredlis...@free.fr a écrit : Hi Sukender, I never tried them, but I know there are some interesting stuff here : http://ftp.acc.umu.se/pub/gnome/binaries/win64/dependencies/ Regards, -Fred - Sukender a écrit : Hi all, I was using gettext-intl to handle translated strings in my apps, but now I'm compiling 64 bits it's a pain having this lib compiled. Do you know where I can find this lib compiled for MSVC10 x64? Do you know other libs (except Qt since it's too heavy for me)? Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Link problem with osgText (latest trunk, MSVC10 x64)
# Greetings loop
foreach(CURRENT_ONE ${OSG-USERS})
message(Hi ${CURRENT_ONE})
endforeach()
:)
I got some problems when linking my app to the latest osgText. It says
osgText::TextNode isn't defined:
unresolved external symbol __declspec(dllimport) public: void __cdecl
osgText::TextNode::setPosition(class osg::Vec3d const )
(__imp_?setposit...@textnode@osgText@@qeaaxaebvve...@osg@@@Z)
unresolved external symbol __declspec(dllimport) public: void __cdecl
osgText::TextNode::setCharacterSize ...
blah blah blah ...
But of course TextNode is there. Everything has been regenerated, recompiled,
checked that it uses Win7.1SDK (or else you run into trouble with x64 + MSVC 10
Express), etc.
Any idea?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Link problem with osgText (latest trunk, MSVC10 x64)
Hi Robert,
Seems not only the inlines. What I reference in my app are inlines however.
Here is the full list:
__declspec(dllimport) public: void __cdecl osgText::TextNode::setPosition(class
osg::Vec3d const )
__declspec(dllimport) public: void __cdecl
osgText::TextNode::setCharacterSize(float)
__declspec(dllimport) public: void __cdecl osgText::TextNode::setFont(class
osgText::Font *)
__declspec(dllimport) public: __cdecl osgText::TextNode::TextNode(void)
public: virtual class osg::Object * __cdecl
osgText::TextNode::cloneType(void)const
public: virtual class osg::Object * __cdecl osgText::TextNode::clone(class
osg::CopyOp const )const
public: virtual bool __cdecl osgText::TextNode::isSameKindAs(class osg::Object
const *)const
public: virtual char const * __cdecl osgText::TextNode::libraryName(void)const
public: virtual char const * __cdecl osgText::TextNode::className(void)const
public: virtual void __cdecl osgText::TextNode::accept(class osg::NodeVisitor )
public: virtual void __cdecl osgText::TextNode::traverse(class osg::NodeVisitor
)
public: virtual void __cdecl osgText::TextNode::update(void)
__declspec(dllimport) protected: virtual __cdecl
osgText::TextNode::~TextNode(void)
I still don't understand, and I don't see the difference with other classes.
( My apologies about the geek greetings... I'm going out - [] ;-) )
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Sukender,
On Tue, Oct 26, 2010 at 8:19 AM, Sukender suky0...@free.fr wrote:
# Greetings loop
foreach(CURRENT_ONE ${OSG-USERS})
message(Hi ${CURRENT_ONE})
endforeach()
:)
GEEK!!! :-)
I got some problems when linking my app to the latest osgText. It
says osgText::TextNode isn't defined:
unresolved external symbol __declspec(dllimport) public: void
__cdecl osgText::TextNode::setPosition(class osg::Vec3d const )
(__imp_?setposit...@textnode@osgText@@qeaaxaebvve...@osg@@@Z)
unresolved external symbol __declspec(dllimport) public: void
__cdecl osgText::TextNode::setCharacterSize ...
blah blah blah ...
But of course TextNode is there. Everything has been regenerated,
recompiled, checked that it uses Win7.1SDK (or else you run into
trouble with x64 + MSVC 10 Express), etc.
Any idea?
I've just looked at the declaration of include/osg/TextNode and the
src/osgText/CMakeLists.txt and I can't spot anything amiss right now.
Is the link error only occuring for the inline methods?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Link problem with osgText (latest trunk, MSVC10 x64)
Argh! Silly me! I recently fixed the output dir for CMake 2.8.2 + MSVC (see
corresponding submission), and thought about clearing /bin... but I forgot to
clean /lib! My app was linking against the old library with the new headers,
hence the error.
Sorry for this.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi Robert,
Seems not only the inlines. What I reference in my app are inlines
however. Here is the full list:
__declspec(dllimport) public: void __cdecl
osgText::TextNode::setPosition(class osg::Vec3d const )
__declspec(dllimport) public: void __cdecl
osgText::TextNode::setCharacterSize(float)
__declspec(dllimport) public: void __cdecl
osgText::TextNode::setFont(class osgText::Font *)
__declspec(dllimport) public: __cdecl
osgText::TextNode::TextNode(void)
public: virtual class osg::Object * __cdecl
osgText::TextNode::cloneType(void)const
public: virtual class osg::Object * __cdecl
osgText::TextNode::clone(class osg::CopyOp const )const
public: virtual bool __cdecl osgText::TextNode::isSameKindAs(class
osg::Object const *)const
public: virtual char const * __cdecl
osgText::TextNode::libraryName(void)const
public: virtual char const * __cdecl
osgText::TextNode::className(void)const
public: virtual void __cdecl osgText::TextNode::accept(class
osg::NodeVisitor )
public: virtual void __cdecl osgText::TextNode::traverse(class
osg::NodeVisitor )
public: virtual void __cdecl osgText::TextNode::update(void)
__declspec(dllimport) protected: virtual __cdecl
osgText::TextNode::~TextNode(void)
I still don't understand, and I don't see the difference with other
classes.
( My apologies about the geek greetings... I'm going out - [] ;-)
)
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Sukender,
On Tue, Oct 26, 2010 at 8:19 AM, Sukender suky0...@free.fr wrote:
# Greetings loop
foreach(CURRENT_ONE ${OSG-USERS})
message(Hi ${CURRENT_ONE})
endforeach()
:)
GEEK!!! :-)
I got some problems when linking my app to the latest osgText. It
says osgText::TextNode isn't defined:
unresolved external symbol __declspec(dllimport) public: void
__cdecl osgText::TextNode::setPosition(class osg::Vec3d const )
(__imp_?setposit...@textnode@osgText@@qeaaxaebvve...@osg@@@Z)
unresolved external symbol __declspec(dllimport) public: void
__cdecl osgText::TextNode::setCharacterSize ...
blah blah blah ...
But of course TextNode is there. Everything has been regenerated,
recompiled, checked that it uses Win7.1SDK (or else you run into
trouble with x64 + MSVC 10 Express), etc.
Any idea?
I've just looked at the declaration of include/osg/TextNode and the
src/osgText/CMakeLists.txt and I can't spot anything amiss right
now.
Is the link error only occuring for the inline methods?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] New osgText library - Questions
Hi all, When updating to latest trunk, I faced the refactoring of osgText. Of course my app has been updated to fit this change, but I don't know how to get the old behaviour back. Can someone assist me? How must I transform these when I got a TextNode*? 1. setAlignment(osgText::Text::LEFT_TOP) 2. setColor() (I guess it's Stateset Material Diffuse) 3. setBackdropType() / setBackdropColor() / setColorGradientMode() / setColorGradientCorners()... Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Wrong CMake output directory using Visual - half submission
Hi Chuck,
Your point of view joins mine. Thanks for clarification.
Be careful however: you wrote *_DEBUG and *_RELEASE. This is half true, because
CMake has 4 configurations by default, and users can change them. So if I
rename Release to Zrolbgluck (or add this new configuration), you'll have
to write *_ZROLBGLUCK. Hence the FOREACH() loop I wrote in my previous email,
which does the job fo every defined configuration.
I'll make a sumbissions this morning I guess/hope.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Chuck Seberino seber...@energid.org a écrit :
Sukender,
It is indeed related to CMake = 2.8.1. I have had success setting all
configuration types including the generic one, which seems to work on
Linux, OSX and Windows. So:
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${OUTPUT_LIBDIR})
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE ${OUTPUT_LIBDIR})
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_DEBUG ${OUTPUT_LIBDIR})
That way it works with older and newer versions of CMake. Older
versions don't know/use/ignore the specific configuration types and
newer CMake uses the most specific setting.
The conditional below I use for other situations. It works for me
since I am simply checking against previous versions:
# CMake = 2.8.1 changed the output directory algorithm...
if (CMAKE_CONFIGURATION_TYPES AND NOT APPLE)
if (${CMAKE_MAJOR_VERSION} EQUAL 2 AND
(${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION} LESS 8.1))
#Perform 'old' CMake method.
# ...
endif ()
endif ()
HTH
Chuck Seberino
On Oct 22, 2010, at 11:13 AM, Sukender wrote:
Hi Robert, hi all,
I spotted the binaries are not in /bin as usual with my new config
(CMake 2.8.2, VS2010 x64), but in /bin/Debug and /bin/Release.
I think CMake 2.8.2 is the cause because the usual way to work around
these subdirs should not work anymore (SET_TARGET_PROPERTIES(Target
PROPERTIES PREFIX ../)). I found a way to make it work properly.
However I don't post it as a submussion because I didn't test it as it
should (not tested under Linux), and I guess we must write some
versionning code (if cmake version is below x.y.z...). Here is my
code, to be put in the root CMakeLists.txt:
Instead of using
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${OUTPUT_LIBDIR})
and such, use:
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_CONFIG ${OUTPUT_LIBDIR})
So the code should look like:
FOREACH(CONF ${CMAKE_CONFIGURATION_TYPES})
STRING(TOUPPER ${CONF} CONF)
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_LIBDIR})
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_BINDIR})
IF(WIN32)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_BINDIR})
ELSE()
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_LIBDIR})
ENDIF()
ENDFOREACH()
Hope someone will take a few minutes to write a nice CMake script (and
figure out the version number from which this can bu used, if this is
really 100% CMake related)
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [OT] I18N libraries
Hi all, I was using gettext-intl to handle translated strings in my apps, but now I'm compiling 64 bits it's a pain having this lib compiled. Do you know where I can find this lib compiled for MSVC10 x64? Do you know other libs (except Qt since it's too heavy for me)? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Wrong CMake output directory using Visual - half submission
Hi Robert, hi all,
I spotted the binaries are not in /bin as usual with my new config (CMake
2.8.2, VS2010 x64), but in /bin/Debug and /bin/Release.
I think CMake 2.8.2 is the cause because the usual way to work around these
subdirs should not work anymore (SET_TARGET_PROPERTIES(Target PROPERTIES
PREFIX ../)). I found a way to make it work properly. However I don't post it
as a submussion because I didn't test it as it should (not tested under Linux),
and I guess we must write some versionning code (if cmake version is below
x.y.z...). Here is my code, to be put in the root CMakeLists.txt:
Instead of using
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${OUTPUT_LIBDIR})
and such, use:
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_CONFIG ${OUTPUT_LIBDIR})
So the code should look like:
FOREACH(CONF ${CMAKE_CONFIGURATION_TYPES})
STRING(TOUPPER ${CONF} CONF)
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_LIBDIR})
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_BINDIR})
IF(WIN32)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_BINDIR})
ELSE()
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_LIBDIR})
ENDIF()
ENDFOREACH()
Hope someone will take a few minutes to write a nice CMake script (and figure
out the version number from which this can bu used, if this is really 100%
CMake related)
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
Hi all,
Any update on this side? I've got the same issue (I use fstream in my project
which depends on osgDB, under VC2010 x64).
Or is there a way to temporarily workaround this in OSG with an ugly #ifdef?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Anders Backman ande...@cs.umu.se a écrit :
Ok, I have localized the problem.
For example, the class osgDB::fstream:
class OSGDB_EXPORT fstream : public std::fstream
{
};
which just inherits from std:.fstream causes the symbols of
std::fstream to be exposed into osgDB.dll
This effectively means that It might cause problems for people linking
against osgDB.dll later on.
Same goes for inheriting from std::string, std::ostringstream etc.
This must obviously be a bug, a very serious one in VS2010.
We had a class derived from std::ostringstream, which exposed the
symbols in the vtable for the class:
namespace ns
{
class Notify : public std::ostringstream
{
};
}
Using depends.exe to analyze the dll-file gives:
const ns::Notify::`vftable'{for `std::basic_ostringstreamchar,struct
std::char_traitschar,class std::allocatorchar '}
My issue was reported to the msdn forum. Their first take was: Oh you
use CMake, thats not our product :-)
But in later threads, they tried to reproduce the problem without
luck...
So if you manage to reproduce this in a small example, go ahead and
post it. We must make them aware of this problem.
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/191de00a-53c9-4bd9-9cb6-e844eb224ca2
/Anders
On Mon, Aug 30, 2010 at 4:31 AM, Christiansen, Brad
brad.christian...@thalesgroup.com.au wrote:
Hi,
Unfortunately I can't offer a solution, but I thought I would mention
I have come across this exact problem and have also pulled my hair out
trying to find a solution. This same problem exists when building
virtual planet builder, linking with osgDB causes the multiply defined
symbols. I had no other issues building the 3rd party libs and osg
with 2010.
The only way I could move forward was to allow multiply defined
symbols (as has already been mentioned). I agree this seems dangerous
and is not a solution but it has allowed me to continue working. So
far it hasn’t caused any issues with my vpb build.
Given you have used the streams extensively without issue and it seems
osgDB is the source of the trouble, have you had a look to see if
there is any discernable difference between your code and that in
osgDB ?
I would love to find a solution to this.
Cheers,
Brad
From: osg-users-boun...@lists.openscenegraph.org [mailto:
osg-users-boun...@lists.openscenegraph.org ] On Behalf Of Anders
Backman
Sent: Friday, 27 August 2010 4:00 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OT: VS2010 LNK2005 problem related to
ostringstream
I have verified the build mode for all ingoing libraries.
I build all the dependencies myself. Including OSG.
The problem I have (which is OSG related), is that if I build without
OSG support (no rendering), it all works.
And I still use std::ostringstream and std::stringstream quite
extensively...
We still link against OpenThreads (but no rendering).
So only when I link against osg (osg.lib, osgDB.lib, osgText.lib,
osgShadow.lib, osgViewer.lib osgGA.lib) I get this problem.
I have verified that osg (and OpenThreads) are all built consistently
all over the field. Release and /MD (MultiThreadedDLL), which is
default from CMake.
So I can use/link against OpenThreads.lib, but not OSG...
Rather nasty problem, I'm trying to reduce it, but I'm getting
nowhere.
And once again, same settings, same CMake version, same code all over
the place, and it works in VS2008...
/A
On Thu, Aug 26, 2010 at 8:17 PM, Simon Hammett
s.d.hamm...@googlemail.com wrote:
Ah ok, then next things to check:
Make absolutely sure you aren't mixing up objects libraries from the
different builds.
For my projects I include a vc version number in the name, so
.vc7.lib/vc7.dll .vc9.lib/.vc9.dll
and I also use the vc version in the name of output intermediate
directory
Then check all the code for any use of
#pragma comment(lib, libname)
and make sure any preprocessor guards that select different versions
have been updated to know about vc2010.
On 26 August 2010 18:37, Anders Backman ande...@cs.umu.se wrote:
Well, I have verified that ALL the dependencies Im using are all built
with /MD and NOT debug.
Im building all of the dependencies for osg and our lib myself, so I
got full control.
Also, as I wrote before, I have even tried to build our libs using
project files generated from cmake vs2008, build with vs2008 -
works ok.
Open same project files
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
T_T ...Going to hang myself...
Not even an idea of a workaround that would be a bit less ugly? Well, if this
is the only way...
Thanks, anyway! ;)
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Frederic Bouvier fredlis...@free.fr a écrit :
Hi Sukender,
Add /FORCE:MULTIPLE to your link options
-Fred
- Sukender a écrit :
Hi all,
Any update on this side? I've got the same issue (I use fstream in
my
project which depends on osgDB, under VC2010 x64).
Or is there a way to temporarily workaround this in OSG with an ugly
#ifdef?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Anders Backman ande...@cs.umu.se a écrit :
Ok, I have localized the problem.
For example, the class osgDB::fstream:
class OSGDB_EXPORT fstream : public std::fstream
{
};
which just inherits from std:.fstream causes the symbols of
std::fstream to be exposed into osgDB.dll
This effectively means that It might cause problems for people
linking
against osgDB.dll later on.
Same goes for inheriting from std::string, std::ostringstream etc.
This must obviously be a bug, a very serious one in VS2010.
We had a class derived from std::ostringstream, which exposed the
symbols in the vtable for the class:
namespace ns
{
class Notify : public std::ostringstream
{
};
}
Using depends.exe to analyze the dll-file gives:
const ns::Notify::`vftable'{for
`std::basic_ostringstreamchar,struct
std::char_traitschar,class std::allocatorchar '}
My issue was reported to the msdn forum. Their first take was: Oh
you
use CMake, thats not our product :-)
But in later threads, they tried to reproduce the problem without
luck...
So if you manage to reproduce this in a small example, go ahead
and
post it. We must make them aware of this problem.
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/191de00a-53c9-4bd9-9cb6-e844eb224ca2
/Anders
On Mon, Aug 30, 2010 at 4:31 AM, Christiansen, Brad
brad.christian...@thalesgroup.com.au wrote:
Hi,
Unfortunately I can't offer a solution, but I thought I would
mention
I have come across this exact problem and have also pulled my hair
out
trying to find a solution. This same problem exists when building
virtual planet builder, linking with osgDB causes the multiply
defined
symbols. I had no other issues building the 3rd party libs and osg
with 2010.
The only way I could move forward was to allow multiply defined
symbols (as has already been mentioned). I agree this seems
dangerous
and is not a solution but it has allowed me to continue working.
So
far it hasn’t caused any issues with my vpb build.
Given you have used the streams extensively without issue and it
seems
osgDB is the source of the trouble, have you had a look to see if
there is any discernable difference between your code and that in
osgDB ?
I would love to find a solution to this.
Cheers,
Brad
From: osg-users-boun...@lists.openscenegraph.org [mailto:
osg-users-boun...@lists.openscenegraph.org ] On Behalf Of Anders
Backman
Sent: Friday, 27 August 2010 4:00 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OT: VS2010 LNK2005 problem related to
ostringstream
I have verified the build mode for all ingoing libraries.
I build all the dependencies myself. Including OSG.
The problem I have (which is OSG related), is that if I build
without
OSG support (no rendering), it all works.
And I still use std::ostringstream and std::stringstream quite
extensively...
We still link against OpenThreads (but no rendering).
So only when I link against osg (osg.lib, osgDB.lib, osgText.lib,
osgShadow.lib, osgViewer.lib osgGA.lib) I get this problem.
I have verified that osg (and OpenThreads) are all built
consistently
all over the field. Release and /MD (MultiThreadedDLL), which is
default from CMake.
So I can use/link against OpenThreads.lib, but not OSG...
Rather nasty problem, I'm trying to reduce it, but I'm getting
nowhere.
And once again, same settings, same CMake version, same code all
over
the place, and it works in VS2008...
/A
On Thu, Aug 26, 2010 at 8:17 PM, Simon Hammett
s.d.hamm...@googlemail.com wrote:
Ah ok, then next things to check:
Make absolutely sure you aren't mixing up objects libraries from
the
different builds.
For my projects I include a vc version number in the name, so
.vc7.lib/vc7.dll .vc9.lib/.vc9.dll
and I
[osg-users] Need help about key mapping (introspection)
Hi all, I used to make a keyboard mapping using introspection in previous versions of OSG, but I'm a bit lost with new wrappers/serializers/whatever. Can anyone tell me how to make a link between a key/mouse button textual representation (ex: KEY_space, KEY_minus), and its value, so that users can have an key mapping file? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Need help about key mapping (introspection)
Many thanks Wang. I'll do that.. because having to carry the burden of wrappers (I mean compile+integrate) is too much for me :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Wang Rui wangra...@gmail.com a écrit : Hi Sukender, Serializers are only used for serialization IO of native formats (osgt/osgb/osgx) at present. If you mean to bind enum values to texts for reading/writing from files, the macros BEGIN_ENUM_SERIALIZER, END_ENUM_SERIALIZER and ADD_ENUM_VALUE can work and there are plenty of examples in the wrappers/serializers folder. Cheers, Wang Rui 2010/10/17 Sukender suky0...@free.fr Hi all, I used to make a keyboard mapping using introspection in previous versions of OSG, but I'm a bit lost with new wrappers/serializers/whatever. Can anyone tell me how to make a link between a key/mouse button textual representation (ex: KEY_space, KEY_minus), and its value, so that users can have an key mapping file? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Use of _wfopen() in FileUtils.cpp = Windows only ?
Hi Robert, I'm ready to help, but unfortunately I got back to Windows development... I guess It'll be a long time before I'll submit something useful. Sorry. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Tue, Oct 12, 2010 at 10:22 PM, Sukender suky0...@free.fr wrote: I just tried to compile latest trunk with OSG_USE_UTF8_FILENAME = true and found it can't compile under linux (Ubuntu, 32 bits). gcc says it can't find _wfopen(). A quick web search indicates this is Windows only. Am I wrong? Is there something I didn't spot? Or should we look for a portable equivalent? I don't think I've recently compiled with OSG_USE_UTF8_FILENAME recently so having a regression creep that hasn't yet been spotted might not be too surprising. Finding a portable equivalent or having #if defined(_WIN32) etc. code paths for each specific implementation is what we'll need to do. Would you be volunteering ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Use of _wfopen() in FileUtils.cpp = Windows only ?
Hi Robert, hi all, I just tried to compile latest trunk with OSG_USE_UTF8_FILENAME = true and found it can't compile under linux (Ubuntu, 32 bits). gcc says it can't find _wfopen(). A quick web search indicates this is Windows only. Am I wrong? Is there something I didn't spot? Or should we look for a portable equivalent? Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [3rdParty] VC10 (express) 64 bits precompiled binaries
Hi all, I'm currently compiling some 3rdParty libs in 64 bits (x86_64) using Visual C++ 2010 Express. However, going 64 bits is sometimes tricky: - Anyone already did it? - Anyone with some useful tips? Already compiled: - Glut (Well, freeglut) - Freetype 2 - jpeg - zlib - png - tiff In progress: - collada dom (having some problems as underlying boost ins't up-to-date) Missing libs are: - Qt - GDAL - libcurl (I once ported it to CMake but it's not maintained by curl devs) - lua - gif - vrpn OSG compiles well (when ignoring errors due to problematic dependencies). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Job offer in Paris/Montbéliard (in F rench)
Hi all, This is a job offer for French+English speaking people, so sorry if you don't read French :) Développement 3D orienté SIG Contrat : CDI ou CDD Lieu : Paris. Possibilité poste sur Montbéliard. Disponibilité : fin septembre 2010 Compétences requises : C++ (développeur expérimenté), géométrie 3D Compétences appréciées : OSG (très apprécié, évidemment), boost, outils SIG, SDK 3DSMax, C#/Java, Qt Plus d'info ? Contactez suky0001 at free dot fr Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] COLLADA writer textures
Hi Gareth, I worked a bit on DAE plugin and as far as I know it should correctly export images... I'm sorry I don't have more info, but you may try having a look using a debugger... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Gareth Ferneyhough garet...@gmail.com a écrit : Hello. I am trying to convert a .ive model to .dae using the collada plugin. It seemed to work fine, but no textures show in blender when I import it. Is this expected? Is there a way to get textures to export properly? I ask because I have been converting to .flt which was working well, and everything imported properly into blender, except for a large scene (70 MB) which would never import (just sat there for hours). I really need it, so I thought I would try the COLALDA route. Any help or suggestions would be appreciated. Thanks, Gareth -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30483#30483 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Footprint algorithm
Hi all, Does anyone knows a (preferably free/open source) code computing either: - The footprint polygons of a building (intersection with terrain) - The footprint polygons of a building (intersection with a single plane) - The conntour polygons of a projected building ? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Double precision tessellator, optimizer, and such
Hi Robert, hi all, I need double precision things in my app, and had to code things like Tessellatord, a double precision version of Tessellator (already submitted). However, I would like to have something cleaner to submit, such as a unique tesselator class that handle both single and double precision values. I need your advice: according to you, what is the best way to code this? Some ideas: - Duplicate code (VERY ugly) - Make the class templated (ugly) - Make a templated class that would be used by the Tessellator (still ugly) - Create/use an array adapter (Vec*Array would be encapsulated, and Tessellator would use it instead of direclty reading the array) - ... other ideas? Thanks. I'll try to apply this to other classes after. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Double precision tessellator, optimizer, and such
Hi Robert, Thanks for the answer. However, I won't be able to write the non-GLU code. I guess making it work with GLU first would be nice... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, I single Tessellator class is the right way to go, one could possible make parts of the implementation templated but keep the interface the same for both cases. One other thing to bare in mind is that OpenGL ES and for OpenGL 3.x/4.x GLU is no longer available so we need to replace all the OSG's GLU code for the OSG to be fully functionality across all OpenGL targets. Robert. On Mon, Jul 26, 2010 at 8:32 AM, Sukender suky0...@free.fr wrote: Hi Robert, hi all, I need double precision things in my app, and had to code things like Tessellatord, a double precision version of Tessellator (already submitted). However, I would like to have something cleaner to submit, such as a unique tesselator class that handle both single and double precision values. I need your advice: according to you, what is the best way to code this? Some ideas: - Duplicate code (VERY ugly) - Make the class templated (ugly) - Make a templated class that would be used by the Tessellator (still ugly) - Create/use an array adapter (Vec*Array would be encapsulated, and Tessellator would use it instead of direclty reading the array) - ... other ideas? Thanks. I'll try to apply this to other classes after. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Double precision tessellator, optimizer, and such
Going to check. Thanks for the info. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Mon, Jul 26, 2010 at 9:24 AM, Sukender suky0...@free.fr wrote: Thanks for the answer. However, I won't be able to write the non-GLU code. I guess making it work with GLU first would be nice... I have wondered about whether we could use the osgUtil::DelaunayTriangulator to implement osgUtil::Tessellator. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Double precision tessellator, optimizer, and such
Maybe a good idea, but DelaunayTriangulator is single precision only, and there is a lot of code. I must admit I don't have enough time for porting DelaunayTriangulator yet. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Mon, Jul 26, 2010 at 9:24 AM, Sukender suky0...@free.fr wrote: Thanks for the answer. However, I won't be able to write the non-GLU code. I guess making it work with GLU first would be nice... I have wondered about whether we could use the osgUtil::DelaunayTriangulator to implement osgUtil::Tessellator. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBX reading of GL_POLYGON
Alright then. Hope the algorithm works for all cases. I tested it a bit more, and as far as I can tell it seems okay. Please keep us (I mean the mailing list) in touch. Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Michael Platings mplati...@gmail.com a écrit : I've had a quick look but I'm going to need to rewrite it to fit with newer code so it's on my to-do list. On 13 July 2010 16:16, Sukender suky0...@free.fr wrote: Hi Michael, hi all, Sorry to push this topic up, but did you test the code (anyone)? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Hi Michael, I managed to write the code, but I need testing. Moreover I can't update the FBX plugin because of the regression I told you in another thread, concerning images. Can you, please: - Merge changes to your working copy, and - Make a few tests with your models? Also feel free to commit if everything seems okay. Attached file is against rev. 11322 of the trunk. Many thanks. For info, my implemtation looks like: - Add points of the triangles - Detect how to split quads (02 or 13), and add points for the two triangles - Save polygons in a temporary array - Add a primitive set for all triangles (DrawArray) - Add polygons points AFTER the points of the triangles - Add primitive sets for polygons - Tessellate Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Alright. I started working on it. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Oh, right, sorry I didn't spot this. Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Michael Platings mplati...@gmail.com a écrit : I was referring to that by For quads I imagine it would be possible to write some fast specialised code to see if they should be split across vertices (0,2) or (1,3) so that loading times remain bearable. On 6 July 2010 09:02, Sukender suky0...@free.fr wrote: Oh... What about concave quads (I mean 4 points polygons)? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : OK. If you got time for this before I do... :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Michael Platings mplati...@gmail.com a écrit : Waht you could do is leave all the triangles and quads in one PrimitiveSet (like it is already), but put each polygon with =5 vertices in it's own PrimitiveSet with Mode=POLYGON. Then run the Tesselator on the Geometry which should tesselate the polygons automagically. On 5 July 2010 13:49, Sukender suky0...@free.fr wrote: Hi Michael, Yes, sorry about OpenGL interpretation of polygons, I forgot that. Well actually, I guess the reader has to handle most (all?) cases. So I suggest to have something like: - If number of points = 4, use current code. - Else call GLU tesselation. Do you agree? The problem I have is that osgUtil::Tessellator is intended to operate on osg's structures. Any idea on how to make it work easily in the reader plugin? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Michael Platings mplati...@gmail.com a écrit : No, 1 to 1 mapping of primitives isn't possible because OpenGL doesn't render concave polygons correctly (in practice GL_POLYGON is the same as GL_TRIANGLE_FAN). Tesselation is possible via GLU but very slow so we need to be careful about how we use that. Most models I've come across have many triangles and quads but few polygons =5 vertices. If we apply triangulation to those few polygons then most models will be unaffected. For quads I imagine it would be possible to write some fast specialised code to see if they should be split across vertices (0,2) or (1,3) so that loading times remain bearable. However, if your content provider could just produce models that are already suitable for real-time rendering that would be best ;) On 5 July 2010 09:09
