Re: [osg-users] Bones Animation

2010-08-26 Thread Paul Martz

Bruno Dias wrote:

Hi,

I'm kind a new in OSG context. I would like to know if someone know or has an 
sample of how can i move the bones of an .FBX model.

I'm trying to develop a virtual hand that you can translate and move your 
fingers trough some sensors in your real hand. I'm already rendering de .fbx 
model and translating it in the scene but i'm stucked in the finger bones 
moving. The .fbx hand sure has bones.

If somebody could help me i would appreciate a lot!
... 


I already have something similar working, just using MatrixTransforms at the 
knuckle joints. What additional functionality do you hope to achieve by using 
FBX bones? Hardware skinning?


--
  -Paul Martz  Skew Matrix Software
   http://www.skew-matrix.com/
___
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

2010-08-26 Thread Simon Hammett
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  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 in vs2010 -> problem occurs.
>
> Im using buildscripts to build dependencies, and it all works for vs2008...
> No external libraries, everything is built from code.
>
> For VS2010, all the dependencies (including osg 2.8.3) builds/links fine.
> But for my libs, I get the linking errors.
>
> Allowing multiple symbols sounds dangerous, and it did not resolve my
> problem...
>
> /A
>
> On Thu, Aug 26, 2010 at 7:26 PM, Simon Hammett  > wrote:
>
>>
>>
>> On 26 August 2010 17:35, Anders Backman  wrote:
>>
>> 
>>
>>
>>  CMake defaults to /MD code generation (MultiThreaded). Im using this
>>> consistently over all my libraries (just double checked to be sure).
>>>
>>
>> Never use that setting unless you know what you are doing.
>>
>> Change every project to
>>
>> Multi-threaded Debug DLL (/MDd) for Debug builds and
>> Multi-threaded DLL (/MD) for Release builds
>>
>> And it will all start working.
>>
>> Those Runtime library settings are the number one 'gotch-ya' for Visual
>> studio, and Cmake defaulting to them is daft.
>>
>> --
>> http://www.ssTk.co.uk
>>
>> ___
>> 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
>
>


-- 
http://www.ssTk.co.uk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Bones Animation

2010-08-26 Thread Buckley, Bob CTR MDA/DES
I picked up a copy of "Game Engine Architecture" by Jason Gregory at SIGGRAPH.
Appears that he covers a huge breadth of the genre, where's he's focused.
There's an animation chapter in there that includes skeletons and skinning.
I'm about a 3rd the way thru so far and can't comment on that particular 
chapter.
However, I'm betting it's a viable resource - at that level.
Probably not good for detailed implementation.

Bob

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Daly
Sent: Thursday, August 26, 2010 12:00 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Bones Animation

Bruno Dias wrote:
> Hi,
>
> I'm kind a new in OSG context. I would like to know if someone know or has an 
> sample of how can i move the bones of an .FBX model.
>
> I'm trying to develop a virtual hand that you can translate and move your 
> fingers trough some sensors in your real hand. I'm already rendering de .fbx 
> model and translating it in the scene but i'm stucked in the finger bones 
> moving. The .fbx hand sure has bones.
>
> If somebody could help me i would appreciate a lot!
>   

Hi, Bruno,

There are a few examples that deal with skinning and animation (they all 
have "osganimation" in their name).  You might want to start there.

--"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] Bones Animation

2010-08-26 Thread Jason Daly

Bruno Dias wrote:

Hi,

I'm kind a new in OSG context. I would like to know if someone know or has an 
sample of how can i move the bones of an .FBX model.

I'm trying to develop a virtual hand that you can translate and move your 
fingers trough some sensors in your real hand. I'm already rendering de .fbx 
model and translating it in the scene but i'm stucked in the finger bones 
moving. The .fbx hand sure has bones.

If somebody could help me i would appreciate a lot!
  


Hi, Bruno,

There are a few examples that deal with skinning and animation (they all 
have "osganimation" in their name).  You might want to start there.


--"J"

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Bones Animation

2010-08-26 Thread Bruno Dias
Hi,

I'm kind a new in OSG context. I would like to know if someone know or has an 
sample of how can i move the bones of an .FBX model.

I'm trying to develop a virtual hand that you can translate and move your 
fingers trough some sensors in your real hand. I'm already rendering de .fbx 
model and translating it in the scene but i'm stucked in the finger bones 
moving. The .fbx hand sure has bones.

If somebody could help me i would appreciate a lot!
... 

Thank you!

Cheers,
Bruno

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=31076#31076





___
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

2010-08-26 Thread Anders Backman
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 in vs2010 -> problem occurs.

Im using buildscripts to build dependencies, and it all works for vs2008...
No external libraries, everything is built from code.

For VS2010, all the dependencies (including osg 2.8.3) builds/links fine.
But for my libs, I get the linking errors.

Allowing multiple symbols sounds dangerous, and it did not resolve my
problem...

/A

On Thu, Aug 26, 2010 at 7:26 PM, Simon Hammett
wrote:

>
>
> On 26 August 2010 17:35, Anders Backman  wrote:
>
> 
>
>
>  CMake defaults to /MD code generation (MultiThreaded). Im using this
>> consistently over all my libraries (just double checked to be sure).
>>
>
> Never use that setting unless you know what you are doing.
>
> Change every project to
>
> Multi-threaded Debug DLL (/MDd) for Debug builds and
> Multi-threaded DLL (/MD) for Release builds
>
> And it will all start working.
>
> Those Runtime library settings are the number one 'gotch-ya' for Visual
> studio, and Cmake defaulting to them is daft.
>
> --
> http://www.ssTk.co.uk
>
> ___
> 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: VS2010 LNK2005 problem related to ostringstream

2010-08-26 Thread Simon Hammett
On 26 August 2010 17:35, Anders Backman  wrote:



 CMake defaults to /MD code generation (MultiThreaded). Im using this
> consistently over all my libraries (just double checked to be sure).
>

Never use that setting unless you know what you are doing.

Change every project to

Multi-threaded Debug DLL (/MDd) for Debug builds and
Multi-threaded DLL (/MD) for Release builds

And it will all start working.

Those Runtime library settings are the number one 'gotch-ya' for Visual
studio, and Cmake defaulting to them is daft.

-- 
http://www.ssTk.co.uk
___
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

2010-08-26 Thread Chuck Seberino
In the application properties:

Configuration Properties -> Linker -> General -> Force File Output -> Multiply 
Defined Symbol Only (/FORCE:MULTIPLE)

Chuck

On Aug 26, 2010, at 10:11 AM, Anders Backman wrote:

> How do you allow multiple symbols in VisualStudio?
> /A
> 
> On Thu, Aug 26, 2010 at 6:51 PM, Chuck Seberino  wrote:
> Anders,
> 
> It is somewhat relevant to OSG too, in that linking against osgDB and other 
> code that uses  will cause similar 'multiple-defined'  linker 
> errors.  This problem seems to be only with MSVC2010, the OS doesn't seem to 
> matter (I use XP).  osgDB is affected because of osgDB::fstream, which 
> subclasses from std::fstream.  The current workaround is to allow multiple 
> symbols when linking.  I would be interested in finding a better solution to 
> this problem...
> 
> Chuck
> 
> 
> On Aug 26, 2010, at 9:35 AM, Anders Backman wrote:
> 
>> Hi all.
>> 
>> This is not related to OSG in any way, but as there so many experts on the 
>> list, I thought I should take the opportunity to ask this...
>> 
>> I have a problem related to linking in VS2010.
>> 
>> Im using VS2010 under Windows 7 (64).
>> 
>> Im building a large source package which is divided into two separate 
>> libraries (dynamic linking: .lib, .dll).
>> 
>> in the first library, a.lib we are using both std::stringstream and 
>> std::ostringstream. a.lib depends on other libraries, all built by myself 
>> using CMake and VS2010. CMake defaults to /MD code generation 
>> (MultiThreaded). Im using this consistently over all my libraries (just 
>> double checked to be sure).
>> 
>> When I build the next library, b.lib, which depends on a.lib, I get the 
>> following linking errors:
>> 
>> 
>> 
>> Linking of b.lib:
>> 
>> 1>a.lib(a.dll) : error LNK2005: "public: void __thiscall 
>> std::basic_ostringstream,class 
>> std::allocator >::`vbase destructor'(void)" 
>> (??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ)
>>  already defined in ImageCapture.obj
>> 
>> 
>> 1>a.lib(a.dll) : error LNK2005: "public: class std::basic_string> std::char_traits,class std::allocator > __thiscall 
>> std::basic_ostringstream,class 
>> std::allocator >::str(void)const " 
>> (?...@?$basic_ostringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz)
>>  already defined in ImageCapture.obj
>> 
>> 1>a.lib(a.dll) : error LNK2005: "public: __thiscall 
>> std::basic_ostringstream,class 
>> std::allocator >::basic_ostringstream> std::char_traits,class std::allocator >(int)" 
>> (??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z)
>>  already defined in ImageCapture.obj
>> 
>> 
>>  
>> Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of 
>> std::ostringstream.
>> 
>> And everything builds.
>> 
>> Next, I try to use std::ostringstream in some other cpp file of the b.lib, 
>> so I just copy the code from ImageCapture.cpp into another .cpp file in 
>> b.lib, including the #include directives...
>> 
>> It links just fine.
>> 
>>  
>> 
>> One important thing to mention, all of this works just fine in VS2008.
>> 
>> 
>> 
>> Next, I tried to change from std::ostringstream to std::stringstream in both 
>> a.lib AND b.lib.
>> 
>>  
>> Now I get the same error, but instead its std::stringstream mentioned in the 
>> error message:
>> 
>>  
>> 
>> 2>a.lib(a.dll) : error LNK2005: "public: void __thiscall 
>> std::basic_stringstream,class 
>> std::allocator >::`vbase destructor'(void)" 
>> (??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ)
>>  already defined in ImageCapture.obj
>> 
>> 2>a.lib(a.dll) : error LNK2005: "public: class std::basic_string> std::char_traits,class std::allocator > __thiscall 
>> std::basic_stringstream,class 
>> std::allocator >::str(void)const " 
>> (?...@?$basic_stringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz)
>>  already defined in ImageCapture.obj
>> 
>> 2>a.lib(a.dll) : error LNK2005: "public: __thiscall 
>> std::basic_stringstream,class 
>> std::allocator >::basic_stringstream> std::char_traits,class std::allocator >(int)" 
>> (??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z)
>>  already defined in ImageCapture.obj
>> 
>> 
>> So, the situation is exactly the same, its just changed from 
>> std::ostringstream to std::stringstream.
>> 
>> If I have just the right balance between stringstream and ostringstream, it 
>> builds. Then the problem occurs when I want to build a third library, 
>> depending on both a.lib AND b.lib...
>> 
>> Then it starts all over.
>> 
>> The next thing I did was to generate project files for vs2008, build with 
>> vs2008 (using dependencies built with vs2010), compiles/links just fine. 
>> Except it does not run (incompatible STL, crash in deque).
>> 
>> Ok, so it builds in VS2008. Next was to buil

Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream

2010-08-26 Thread Anders Backman
How do you allow multiple symbols in VisualStudio?
/A

On Thu, Aug 26, 2010 at 6:51 PM, Chuck Seberino wrote:

> Anders,
>
> It is somewhat relevant to OSG too, in that linking against osgDB and other
> code that uses  will cause similar 'multiple-defined'  linker
> errors.  This problem seems to be only with MSVC2010, the OS doesn't seem to
> matter (I use XP).  osgDB is affected because of osgDB::fstream, which
> subclasses from std::fstream.  The current workaround is to allow multiple
> symbols when linking.  I would be interested in finding a better solution to
> this problem...
>
> Chuck
>
>
> On Aug 26, 2010, at 9:35 AM, Anders Backman wrote:
>
> Hi all.
>
> This is not related to OSG in any way, but as there so many experts on the
> list, I thought I should take the opportunity to ask this...
>
> I have a problem related to linking in VS2010.
>
> Im using VS2010 under Windows 7 (64).
>
> Im building a large source package which is divided into two separate
> libraries (dynamic linking: .lib, .dll).
>
> in the first library, a.lib we are using both std::stringstream and
> std::ostringstream. a.lib depends on other libraries, all built by myself
> using CMake and VS2010. CMake defaults to /MD code generation
> (MultiThreaded). Im using this consistently over all my libraries (just
> double checked to be sure).
>
> When I build the next library, b.lib, which depends on a.lib, I get the
> following linking errors:
>
>
> Linking of b.lib:
>
> 1>a.lib(a.dll) : error LNK2005: "public: void __thiscall
> std::basic_ostringstream,class
> std::allocator >::`vbase destructor'(void)"
> (??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ)
> already defined in ImageCapture.obj
>
> 1>a.lib(a.dll) : error LNK2005: "public: class
> std::basic_string,class
> std::allocator > __thiscall std::basic_ostringstream std::char_traits,class std::allocator >::str(void)const " (?str@
> ?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@
> @qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz)
> already defined in ImageCapture.obj
>
> 1>a.lib(a.dll) : error LNK2005: "public: __thiscall
> std::basic_ostringstream,class
> std::allocator >::basic_ostringstream std::char_traits,class std::allocator >(int)"
> (??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@
> @q...@h@Z) already defined in ImageCapture.obj
>
>
>
> Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of
> std::ostringstream.
>
> And everything builds.
>
> Next, I try to use std::ostringstream in some other cpp file of the b.lib,
> so I just copy the code from ImageCapture.cpp into another .cpp file in
> b.lib, including the #include directives...
>
> It links just fine.
>
>
> One important thing to mention, all of this works just fine in VS2008.
>
>
> Next, I tried to change from std::ostringstream to std::stringstream in
> both a.lib AND b.lib.
>
>
> Now I get the same error, but instead its std::stringstream mentioned in
> the error message:
>
>
> 2>a.lib(a.dll) : error LNK2005: "public: void __thiscall
> std::basic_stringstream,class
> std::allocator >::`vbase destructor'(void)"
> (??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ)
> already defined in ImageCapture.obj
>
> 2>a.lib(a.dll) : error LNK2005: "public: class
> std::basic_string,class
> std::allocator > __thiscall std::basic_stringstream std::char_traits,class std::allocator >::str(void)const " (?str@
> ?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@
> @qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz)
> already defined in ImageCapture.obj
>
> 2>a.lib(a.dll) : error LNK2005: "public: __thiscall
> std::basic_stringstream,class
> std::allocator >::basic_stringstream std::char_traits,class std::allocator >(int)"
> (??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@
> @q...@h@Z) already defined in ImageCapture.obj
>
> So, the situation is exactly the same, its just changed from
> std::ostringstream to std::stringstream.
>
> If I have just the right balance between stringstream and ostringstream, it
> builds. Then the problem occurs when I want to build a third library,
> depending on both a.lib AND b.lib...
>
> Then it starts all over.
>
> The next thing I did was to generate project files for vs2008, build with
> vs2008 (using dependencies built with vs2010), compiles/links just fine.
> Except it does not run (incompatible STL, crash in deque).
>
> Ok, so it builds in VS2008. Next was to build everything in vs2010 using
> the same project files. Then I get the above linking error.
>
>
> Im more and more leaning towards a bug in VS2010, but its really hard to
> verify...
>
> Anyone experienced this in VS2010?
>  -
>
>  ___
> 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

2010-08-26 Thread Chuck Seberino
Anders,

It is somewhat relevant to OSG too, in that linking against osgDB and other 
code that uses  will cause similar 'multiple-defined'  linker errors.  
This problem seems to be only with MSVC2010, the OS doesn't seem to matter (I 
use XP).  osgDB is affected because of osgDB::fstream, which subclasses from 
std::fstream.  The current workaround is to allow multiple symbols when 
linking.  I would be interested in finding a better solution to this problem...

Chuck


On Aug 26, 2010, at 9:35 AM, Anders Backman wrote:

> Hi all.
> 
> This is not related to OSG in any way, but as there so many experts on the 
> list, I thought I should take the opportunity to ask this...
> 
> I have a problem related to linking in VS2010.
> 
> Im using VS2010 under Windows 7 (64).
> 
> Im building a large source package which is divided into two separate 
> libraries (dynamic linking: .lib, .dll).
> 
> in the first library, a.lib we are using both std::stringstream and 
> std::ostringstream. a.lib depends on other libraries, all built by myself 
> using CMake and VS2010. CMake defaults to /MD code generation 
> (MultiThreaded). Im using this consistently over all my libraries (just 
> double checked to be sure).
> 
> When I build the next library, b.lib, which depends on a.lib, I get the 
> following linking errors:
> 
> 
> 
> Linking of b.lib:
> 
> 1>a.lib(a.dll) : error LNK2005: "public: void __thiscall 
> std::basic_ostringstream,class 
> std::allocator >::`vbase destructor'(void)" 
> (??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ)
>  already defined in ImageCapture.obj
> 
> 
> 1>a.lib(a.dll) : error LNK2005: "public: class std::basic_string std::char_traits,class std::allocator > __thiscall 
> std::basic_ostringstream,class 
> std::allocator >::str(void)const " 
> (?...@?$basic_ostringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz)
>  already defined in ImageCapture.obj
> 
> 1>a.lib(a.dll) : error LNK2005: "public: __thiscall 
> std::basic_ostringstream,class 
> std::allocator >::basic_ostringstream std::char_traits,class std::allocator >(int)" 
> (??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z)
>  already defined in ImageCapture.obj
> 
> 
>  
> Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of 
> std::ostringstream.
> 
> And everything builds.
> 
> Next, I try to use std::ostringstream in some other cpp file of the b.lib, so 
> I just copy the code from ImageCapture.cpp into another .cpp file in b.lib, 
> including the #include directives...
> 
> It links just fine.
> 
>  
> 
> One important thing to mention, all of this works just fine in VS2008.
> 
> 
> 
> Next, I tried to change from std::ostringstream to std::stringstream in both 
> a.lib AND b.lib.
> 
>  
> Now I get the same error, but instead its std::stringstream mentioned in the 
> error message:
> 
>  
> 
> 2>a.lib(a.dll) : error LNK2005: "public: void __thiscall 
> std::basic_stringstream,class 
> std::allocator >::`vbase destructor'(void)" 
> (??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ)
>  already defined in ImageCapture.obj
> 
> 2>a.lib(a.dll) : error LNK2005: "public: class std::basic_string std::char_traits,class std::allocator > __thiscall 
> std::basic_stringstream,class 
> std::allocator >::str(void)const " 
> (?...@?$basic_stringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz)
>  already defined in ImageCapture.obj
> 
> 2>a.lib(a.dll) : error LNK2005: "public: __thiscall 
> std::basic_stringstream,class 
> std::allocator >::basic_stringstream std::char_traits,class std::allocator >(int)" 
> (??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z)
>  already defined in ImageCapture.obj
> 
> 
> So, the situation is exactly the same, its just changed from 
> std::ostringstream to std::stringstream.
> 
> If I have just the right balance between stringstream and ostringstream, it 
> builds. Then the problem occurs when I want to build a third library, 
> depending on both a.lib AND b.lib...
> 
> Then it starts all over.
> 
> The next thing I did was to generate project files for vs2008, build with 
> vs2008 (using dependencies built with vs2010), compiles/links just fine. 
> Except it does not run (incompatible STL, crash in deque).
> 
> Ok, so it builds in VS2008. Next was to build everything in vs2010 using the 
> same project files. Then I get the above linking error.
> 
> 
> 
> Im more and more leaning towards a bug in VS2010, but its really hard to 
> verify...
> 
> 
> Anyone experienced this in VS2010?
> 
>  -
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

__

[osg-users] OT: VS2010 LNK2005 problem related to ostringstream

2010-08-26 Thread Anders Backman
Hi all.

This is not related to OSG in any way, but as there so many experts on the
list, I thought I should take the opportunity to ask this...

I have a problem related to linking in VS2010.

Im using VS2010 under Windows 7 (64).

Im building a large source package which is divided into two separate
libraries (dynamic linking: .lib, .dll).

in the first library, a.lib we are using both std::stringstream and
std::ostringstream. a.lib depends on other libraries, all built by myself
using CMake and VS2010. CMake defaults to /MD code generation
(MultiThreaded). Im using this consistently over all my libraries (just
double checked to be sure).

When I build the next library, b.lib, which depends on a.lib, I get the
following linking errors:


Linking of b.lib:

1>a.lib(a.dll) : error LNK2005: "public: void __thiscall
std::basic_ostringstream,class
std::allocator >::`vbase destructor'(void)"
(??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ)
already defined in ImageCapture.obj

1>a.lib(a.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > __thiscall
std::basic_ostringstream,class
std::allocator >::str(void)const " (?...@?$basic_ostringstream@DU
?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du
?$char_tra...@d@std@@v?$alloca...@d@2@@2...@xz) already defined in
ImageCapture.obj

1>a.lib(a.dll) : error LNK2005: "public: __thiscall
std::basic_ostringstream,class
std::allocator >::basic_ostringstream,class std::allocator >(int)"
(??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@
@q...@h@Z) already defined in ImageCapture.obj



Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of
std::ostringstream.

And everything builds.

Next, I try to use std::ostringstream in some other cpp file of the b.lib,
so I just copy the code from ImageCapture.cpp into another .cpp file in
b.lib, including the #include directives...

It links just fine.



One important thing to mention, all of this works just fine in VS2008.

Next, I tried to change from std::ostringstream to std::stringstream in both
a.lib AND b.lib.



Now I get the same error, but instead its std::stringstream mentioned in the
error message:



2>a.lib(a.dll) : error LNK2005: "public: void __thiscall
std::basic_stringstream,class
std::allocator >::`vbase destructor'(void)"
(??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ)
already defined in ImageCapture.obj

2>a.lib(a.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > __thiscall
std::basic_stringstream,class
std::allocator >::str(void)const " (?...@?$basic_stringstream@DU
?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du
?$char_tra...@d@std@@v?$alloca...@d@2@@2...@xz) already defined in
ImageCapture.obj

2>a.lib(a.dll) : error LNK2005: "public: __thiscall
std::basic_stringstream,class
std::allocator >::basic_stringstream,class std::allocator >(int)"
(??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z)
already defined in ImageCapture.obj

So, the situation is exactly the same, its just changed from
std::ostringstream to std::stringstream.

If I have just the right balance between stringstream and ostringstream, it
builds. Then the problem occurs when I want to build a third library,
depending on both a.lib AND b.lib...

Then it starts all over.

The next thing I did was to generate project files for vs2008, build with
vs2008 (using dependencies built with vs2010), compiles/links just fine.
Except it does not run (incompatible STL, crash in deque).

Ok, so it builds in VS2008. Next was to build everything in vs2010 using the
same project files. Then I get the above linking error.


Im more and more leaning towards a bug in VS2010, but its really hard to
verify...

Anyone experienced this in VS2010?
 -
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] backface and picking

2010-08-26 Thread Eric Pouliquen
Hi all,

I'm writing a piece of code to know, when a picking occurred, if the picked 
face is orientated backward or  forward... because if I understand well, there 
is no "simple" way to avoid picking results on culled backfaces :


Code:
osgUtil::LineSegmentIntersector::Intersections intersections;

float x = ea.getX();
float y = ea.getY();

osg::ref_ptr< osgUtil::LineSegmentIntersector > picker = new 
osgUtil::LineSegmentIntersector(osgUtil::Intersector::WINDOW, x, y);
osgUtil::IntersectionVisitor iv(picker.get());
iv.setTraversalMask(IS_PICKABLE_MASK);
view->getCamera()->accept(iv);
if (picker->containsIntersections())
{
intersections = picker->getIntersections();
for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr = 
intersections.begin();hitr != intersections.end();++hitr)
{
osg::Vec3 n = hitr->getLocalIntersectNormal();
osg::Vec3 eye = iv.getEyePoint();
osg::Vec3 inter = hitr->getLocalIntersectPoint();

n.normalize();
osg::Vec3 eyeVec = inter-eye;
eyeVec.normalize();

if (eyeVec*n>0)
{
 /*do something */
 }
 }
}



but the results are not what I thought... is there something wrong in my dot 
product computed in local coords just to know if the normal is looking to the 
camera or not ?


Thanks for your help

Eric[/code]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=31073#31073





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Saving the result of an IntersectVisitor

2010-08-26 Thread Todd J. Furlong

Ooh, that could work!  Thanks, Terry, I will try that.

-Todd

On 08/25/2010 05:58 PM, Terry Welsh wrote:

How about just a vector of vector of integers?  Each integer would
represent the nth child of the previous node, and each vector of
integers would represent a whole nodepath.  So "4 6 7" would mean the
7th child of the 6th child of the 4th child of the root node.
--
Terry Welsh
mogumbo 'at' gmail.com
www.reallyslick.com




Message: 14
Date: Wed, 25 Aug 2010 08:44:05 -0400
From: "Todd J. Furlong"
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Saving the result of an IntersectVisitor
Message-ID:<4c751015.3010...@inv3rsion.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi all,

I use an IntersectVisitor to select nodes in a viewer application.  It
works fine, and the first Geode in the hit list is the node I want to
select.  Now I need to record that hit as part of saving the state of
our application in a metadata file that we save alongside a model file
or files.  This is where I've run into a problem.

1. Many of the nodes in our model files are unnamed (lost in
translation, most likely), so I can't store the name of a Geode.
2. NodePaths are vectors of pointers, so they can't help me here.
3. I *could* save intersection rays&  play them back after loading.
That would work, but it would be both slower and not quite in the spirit
of saving the application state.

So, I am throwing this problem out to the folks in the group.  Am I
unaware of an already-existing solution to this?  Or does somebody out
there have a clever idea to help me out?

Thanks in advance,
Todd


___
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] OSG using OpenGL ES 2.0 on IPhone

2010-08-26 Thread Robert Timm
Hello,

In this post I want to report my progress on using OSG with OpenGL ES 2.0 on 
the IPhone.

I am using OSG for my master thesis at the HPI. I needed a cross platform 
rendering system which supports OpenGL ES 2.0 (to have shader support on iOS). 
OSG was the only mature rendering system offering OpenGL ES 2.0 support and 
having some progress on running it on the IPhone.

Building and setting up OSG on Mac and Windows was pretty easy. Luckily, there 
is an OSG fork on GitHub which has an IPhone branch (stmh/osg/tree/iphone). 
Using that branch, I managed to get an OSG sample running on the IPhone 
Simulator. 

I am using Version 4 of the iOS SDK, so I adjusted the Xcode project 
(IPhone_Project/OSGIPhone.xcodeproj) to use version 4 as the base SDK and 
changed the target to version 4 for the simulator.

The only code change I had to make it get it running was:

Code:
diff --git a/src/osgDB/FileUtils.cpp b/src/osgDB/FileUtils.cpp
index 573886a..073beb8 100644
--- a/src/osgDB/FileUtils.cpp
+++ b/src/osgDB/FileUtils.cpp
@@ -51,7 +51,7 @@ typedef char TCHAR;
//>OSG_IPHONE
//IPhone includes
#include "TargetConditionals.h"
- #if (TARGET_OS_IPHONE) && !(TARGET_IPHONE_SIMULATOR) //only when on device
+ #if (TARGET_OS_IPHONE)
#define stat64 stat
#endif
//
#else
#import 
+// in GLES2, the OES suffix if dropped from function names
+#define glGenFramebuffersOES glGenFramebuffers
+#define glGenRenderbuffersOES glGenRenderbuffers
+#define glBindFramebufferOES glBindFramebuffer
+#define glBindRenderbufferOES glBindRenderbuffer
+#define glFramebufferRenderbufferOES glFramebufferRenderbuffer
+#define glGetRenderbufferParameterivOES glGetRenderbufferParameteriv
+#define glRenderbufferStorageOES glRenderbufferStorage
+#define glDeleteRenderbuffersOES glDeleteRenderbuffers
+#define glDeleteFramebuffersOES glDeleteFramebuffers
+#define glCheckFramebufferStatusOES glCheckFramebufferStatus
+
+#define GL_FRAMEBUFFER_OES GL_FRAMEBUFFER
+#define GL_RENDERBUFFER_OES GL_RENDERBUFFER
+#define GL_RENDERBUFFER_WIDTH_OES GL_RENDERBUFFER_WIDTH 
+#define GL_RENDERBUFFER_HEIGHT_OES GL_RENDERBUFFER_HEIGHT
+#define GL_COLOR_ATTACHMENT0_OES GL_COLOR_ATTACHMENT0
+#define GL_DEPTH_ATTACHMENT_OES GL_DEPTH_ATTACHMENT
+#define GL_DEPTH_COMPONENT16_OES GL_DEPTH_COMPONENT16
+#define GL_STENCIL_INDEX8_OES GL_STENCIL_INDEX8
+#define GL_FRAMEBUFFER_COMPLETE_OES GL_FRAMEBUFFER_COMPLETE
+#define GL_STENCIL_ATTACHMENT_OES GL_STENCIL_ATTACHMENT
#endif

#include "IPhoneUtils.h"



Ok. Now OSG builds completely with the OpenGL ES 2 config. But running the 
sample application provided with the IPhone branch 
(IPhone_Project/iphoneExamples/simple/) fails while compiling the shaders. This 
happens due to quite hard restrictions in GLSL ES. This issue seems similar to 
thread #6120 (ShaderGen and OpenGL ES2). I started hacking around in 
src/osgUtil/ShaderGen.cpp, but I think the cleaner solution is to provide 
custom shaders. 

So finally, the OSG application code I am currently running on the IPhone 
(OpenGL ES 2), Windows (OpenGL 2) and Mac OS X (OpenGL 2) looks like this (only 
the essential parts shown):

Code:

#define SHADER_COMPAT \
"#ifndef GL_ES\n" \
"#if (__VERSION__ <= 110)\n" \
"#define lowp\n" \
"#define mediump\n" \
"#define highp\n" \
"#endif\n" \
"#endif\n"

static const char* vertSource = {
SHADER_COMPAT
"// colors a fragment based on its position\n"
"varying mediump vec4 color;\n"
"void main(void) {\n"
"color = gl_Vertex;\n"
"gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n"
"}\n"
};

static const char* fragSource = {
SHADER_COMPAT
"varying mediump vec4 color;\n"
"void main(void) {\n"
"gl_FragColor = clamp( color, 0.0, 1.0 );\n"
"}\n"
};

void Application::init() {

osg::setNotifyLevel(osg::INFO);

m_root = new osg::MatrixTransform();

osg::Geode* geode = new osg::Geode();
osg::ShapeDrawable* drawable = new osg::ShapeDrawable(new osg::Box(osg::Vec3(1, 
1, 1), 1));
geode->addDrawable(drawable);

osg::Program* program = new osg::Program;
program->setName("shader");
program->addShader(new osg::Shader(osg::Shader::VERTEX, vertSource));
program->addShader(new osg::Shader(osg::Shader::FRAGMENT, fragSource));
geode->getOrCreateStateSet()->setAttributeAndModes(program, 
osg::StateAttribute::ON);

m_root->addChild(geode);

m_viewer = new osgViewer::Viewer();

#if !defined(TARGET_OS_IPHONE)
m_viewer->setUpViewInWindow(100, 100, 800, 600, 0);
#endif

m_viewer->setSceneData(m_root.get());
m_viewer->setCameraManipulator(new osgGA::TrackballManipulator);
}




My next step will be to make a textured model load. Here again, the generated 
shaders fail to compile.

Well, I now, this is all no rocket science, but I thought it might be 
interesting for someone though.
Any comments, suggestions and hints are very welcome!

rti

PS: Sorry, the code is not indented, but somehow the forum screws up TABs and 
two or more spaces in a row.
PPS: Sorry, that there are no links in that post, but the forum did not allow 
it since this is my first post.

---

[osg-users] precompiled binaries

2010-08-26 Thread PCJohn

Hi,
I want to contribute precompiled binaries of Inventor/Coin plugin to
https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs80sp1 
and
https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs90sp1 
.

Is there a standard procedure to proceed?

I am willing to maintain and updates the binaries by the new releases of 
Inventor/Coin if I get write access (Do not worry about svn - I am not 
beginner). Otherwise, I can just deliver the binaries. At least one 
person asked me about the binaries, so I think, osgtoy would be a 
natural place to put it.

John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Issue with normal vectors

2010-08-26 Thread Werner Modenbach
Thanks, works great for the quick solution :-)

Am Donnerstag, 26. August 2010 14:32:19 schrieb Werner Modenbach:
> Thanks Robert,
> 
> I'll follow this way. You are right, this is the way to get the quickest
> results.
> 
> - Werner -
> 
> Am Donnerstag, 26. August 2010 14:19:48 schrieb Robert Osfield:
> > Hi Werner,
> > 
> > Possible the most simple and quickest way for you to set things up is
> > to simple create a new vertex, normal and tex coords for every
> > triangle corner, then use osg::DrawArrays(GL_TRIANGLES,
> > total_no_of_new_vertices) for the PrimitiveSet, and BIND_PER_VERTEX
> > for the binding of the normals.  Note, you'll need to create a new
> > Vec3Array for the vertices form the index and orignal vertex data.
> > 
> > This won't be the most efficient route as it's likely to result in
> > duplicate vertices but at least it should be very straight forward.
> > You can make things more efficient later.
> > 
> > Robert.
> > 
> > On Thu, Aug 26, 2010 at 12:08 PM, Werner Modenbach
> > 
> >  wrote:
> > > Thanks Robert, I get closer to it.
> > > 
> > > Just for verification:
> > > 
> > > If I have i.e. 10 vertexes and I get 20 calls to the callback method
> > > each defining a triangle.
> > > Each call gives me 3 indexes, 3 normals and 3 texcoords.
> > > 
> > > Right now I just push everything into the corresponding arrays and at
> > > the
> > > 
> > > end I call:
> > >geometry->addPrimitiveSet(new
> > > 
> > > osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0,
> > > osgVertexIndices->size()));
> > > 
> > > You say this will not work because:
> > > 1) geometry->setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
> > > 
> > >expects just 1 normal for the whole thing (?)
> > > 
> > > 2) Texture coordinates are allways bound per vertex?
> > > 
> > > In this case I have to:
> > > 1) initialize a normal array with Vec3(0.0, 0.0, 0.0)
> > > 
> > >for each triangle callback I have to look on each vertex index , if
> > > 
> > > the indexes normal is 0
> > > 
> > >if yes:  just set it
> > >if no:   duplicate the vertex at the end of the vertexes and
> > > 
> > > push_back the normal
> > > 2) do something comparable on the texcoords
> > > 
> > > Is that your recommendation?
> > > 
> > > Is there any way to bind normals to the vertex indexes?
> > > 
> > > Thanks in advance!
> > > 
> > > - Werner -
> > > 
> > > Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield:
> > >> Hi Werner,
> > >> 
> > >> 
> > >> BIND_PER_PRIMITIVE_SET will mean that you'll have one of the
> > >> associated attribute (i.e. colour, normal) per osg::PrimitiveSet
> > >> attached the osg::Geometry, so if you have one osg::DrawElementsUShort
> > >> used for the triangles then you'll need just one of the associated
> > >> attribute for it.
> > >> 
> > >> BIND_PER_PRIMITIVE will apply the attribute per primitive in you case
> > >> per triangle.
> > >> 
> > >> Tex coords in the OSG are always bound per vertex, there isn't a
> > >> control to alter this.
> > >> 
> > >> If you have a vertex array and indices for your triangles the natural
> > >> thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES)
> > >> then use push_back(tri.p1) for each index on each triangle.
> > >> 
> > >> I would suggest binding the normals per vertex, you'll have to do this
> > >> for the tex coords as well.  If a single vertex will have multiple tex
> > >> coords or multiple normals associated with it due to differences in
> > >> the triangles then you'll need to duplicate the vertices and remap the
> > >> indices on the triangles to fit this.
> > >> 
> > >> Robert.
> > >> 
> > >> On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach
> > >> 
> > >>  wrote:
> > >> > Thank you Paul for your response.
> > >> > 
> > >> > Yes, you are right, the solution isn't perfect at all. But I'm
> > >> > integrating some external code which is just giving me a vertex
> > >> > array and a per triangle callback with vertex indexes and normal
> > >> > and texture coords.
> > >> > 
> > >> > And further more I need some screenshots very urgently for a
> > >> > customer presentation.
> > >> > 
> > >> > The performance improvement has to wait :-(
> > >> > 
> > >> > So I try to analyse why it's not working. And I detected something I
> > >> > don't understand.
> > >> > In my opinion it should give the same result having:
> > >> > 1) one normal per triangle an binding PER_PRIMITIVE
> > >> > 2) 3 times the same normal and binding PER_PRIMITIVE_SET
> > >> > 
> > >> > But it doesn't. So I'm confused.
> > >> > 
> > >> > Thanks for further hints.
> > >> > 
> > >> > - Werner -
> > >> > 
> > >> > Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz:
> > >> >> Werner Modenbach wrote:
> > >> >> > Maybe someone can give me some explanation on my stupid little
> > >> >> > problem.
> > >> >> > 
> > >> >> > I have a geometry being composed of TRIANGLES.
> > >> >> > I have a vertex-array, a verted-index-array and a normal-array
> > >> >> > assigned 

Re: [osg-users] Issue with normal vectors

2010-08-26 Thread Werner Modenbach
Thanks Robert,

I'll follow this way. You are right, this is the way to get the quickest 
results.

- Werner -

Am Donnerstag, 26. August 2010 14:19:48 schrieb Robert Osfield:
> Hi Werner,
> 
> Possible the most simple and quickest way for you to set things up is
> to simple create a new vertex, normal and tex coords for every
> triangle corner, then use osg::DrawArrays(GL_TRIANGLES,
> total_no_of_new_vertices) for the PrimitiveSet, and BIND_PER_VERTEX
> for the binding of the normals.  Note, you'll need to create a new
> Vec3Array for the vertices form the index and orignal vertex data.
> 
> This won't be the most efficient route as it's likely to result in
> duplicate vertices but at least it should be very straight forward.
> You can make things more efficient later.
> 
> Robert.
> 
> On Thu, Aug 26, 2010 at 12:08 PM, Werner Modenbach
> 
>  wrote:
> > Thanks Robert, I get closer to it.
> > 
> > Just for verification:
> > 
> > If I have i.e. 10 vertexes and I get 20 calls to the callback method each
> > defining a triangle.
> > Each call gives me 3 indexes, 3 normals and 3 texcoords.
> > 
> > Right now I just push everything into the corresponding arrays and at the
> > end I call:
> >geometry->addPrimitiveSet(new
> > osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0,
> > osgVertexIndices->size()));
> > 
> > You say this will not work because:
> > 1) geometry->setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
> >expects just 1 normal for the whole thing (?)
> > 2) Texture coordinates are allways bound per vertex?
> > 
> > In this case I have to:
> > 1) initialize a normal array with Vec3(0.0, 0.0, 0.0)
> >for each triangle callback I have to look on each vertex index , if
> > the indexes normal is 0
> >if yes:  just set it
> >if no:   duplicate the vertex at the end of the vertexes and
> > push_back the normal
> > 2) do something comparable on the texcoords
> > 
> > Is that your recommendation?
> > 
> > Is there any way to bind normals to the vertex indexes?
> > 
> > Thanks in advance!
> > 
> > - Werner -
> > 
> > Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield:
> >> Hi Werner,
> >> 
> >> 
> >> BIND_PER_PRIMITIVE_SET will mean that you'll have one of the
> >> associated attribute (i.e. colour, normal) per osg::PrimitiveSet
> >> attached the osg::Geometry, so if you have one osg::DrawElementsUShort
> >> used for the triangles then you'll need just one of the associated
> >> attribute for it.
> >> 
> >> BIND_PER_PRIMITIVE will apply the attribute per primitive in you case
> >> per triangle.
> >> 
> >> Tex coords in the OSG are always bound per vertex, there isn't a
> >> control to alter this.
> >> 
> >> If you have a vertex array and indices for your triangles the natural
> >> thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES)
> >> then use push_back(tri.p1) for each index on each triangle.
> >> 
> >> I would suggest binding the normals per vertex, you'll have to do this
> >> for the tex coords as well.  If a single vertex will have multiple tex
> >> coords or multiple normals associated with it due to differences in
> >> the triangles then you'll need to duplicate the vertices and remap the
> >> indices on the triangles to fit this.
> >> 
> >> Robert.
> >> 
> >> On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach
> >> 
> >>  wrote:
> >> > Thank you Paul for your response.
> >> > 
> >> > Yes, you are right, the solution isn't perfect at all. But I'm
> >> > integrating some external code which is just giving me a vertex array
> >> > and a per triangle callback with vertex indexes and normal and texture
> >> > coords.
> >> > 
> >> > And further more I need some screenshots very urgently for a customer
> >> > presentation.
> >> > 
> >> > The performance improvement has to wait :-(
> >> > 
> >> > So I try to analyse why it's not working. And I detected something I
> >> > don't understand.
> >> > In my opinion it should give the same result having:
> >> > 1) one normal per triangle an binding PER_PRIMITIVE
> >> > 2) 3 times the same normal and binding PER_PRIMITIVE_SET
> >> > 
> >> > But it doesn't. So I'm confused.
> >> > 
> >> > Thanks for further hints.
> >> > 
> >> > - Werner -
> >> > 
> >> > Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz:
> >> >> Werner Modenbach wrote:
> >> >> > Maybe someone can give me some explanation on my stupid little
> >> >> > problem.
> >> >> > 
> >> >> > I have a geometry being composed of TRIANGLES.
> >> >> > I have a vertex-array, a verted-index-array and a normal-array
> >> >> > assigned to my geometry.
> >> >> 
> >> >> Off-topic: Do you need to use the vertex-index-array? It is
> >> >> deprecated: /** deprecated - forces OpenGL slow path, just kept for
> >> >> backwards compatibility.*/
> >> >>  void setVertexIndices(IndexArray* array);
> >> >> 
> >> >> > 3 indexes and 3 normals per Triangle.
> >> >> > Normal binding is set to BIND_PER_PRIMITIVE_SET.
> >> >> > 
> >> >> > Unfortunately the renderi

Re: [osg-users] Issue with normal vectors

2010-08-26 Thread Robert Osfield
Hi Werner,

Possible the most simple and quickest way for you to set things up is
to simple create a new vertex, normal and tex coords for every
triangle corner, then use osg::DrawArrays(GL_TRIANGLES,
total_no_of_new_vertices) for the PrimitiveSet, and BIND_PER_VERTEX
for the binding of the normals.  Note, you'll need to create a new
Vec3Array for the vertices form the index and orignal vertex data.

This won't be the most efficient route as it's likely to result in
duplicate vertices but at least it should be very straight forward.
You can make things more efficient later.

Robert.

On Thu, Aug 26, 2010 at 12:08 PM, Werner Modenbach
 wrote:
> Thanks Robert, I get closer to it.
>
> Just for verification:
>
> If I have i.e. 10 vertexes and I get 20 calls to the callback method each
> defining a triangle.
> Each call gives me 3 indexes, 3 normals and 3 texcoords.
>
> Right now I just push everything into the corresponding arrays and at the end
> I call:
>    geometry->addPrimitiveSet(new
> osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0, osgVertexIndices->size()));
>
> You say this will not work because:
> 1) geometry->setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
>    expects just 1 normal for the whole thing (?)
> 2) Texture coordinates are allways bound per vertex?
>
> In this case I have to:
> 1) initialize a normal array with Vec3(0.0, 0.0, 0.0)
>    for each triangle callback I have to look on each vertex index , if the
>    indexes normal is 0
>        if yes:  just set it
>        if no:   duplicate the vertex at the end of the vertexes and push_back
>                   the normal
> 2) do something comparable on the texcoords
>
> Is that your recommendation?
>
> Is there any way to bind normals to the vertex indexes?
>
> Thanks in advance!
>
> - Werner -
>
> Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield:
>> Hi Werner,
>>
>>
>> BIND_PER_PRIMITIVE_SET will mean that you'll have one of the
>> associated attribute (i.e. colour, normal) per osg::PrimitiveSet
>> attached the osg::Geometry, so if you have one osg::DrawElementsUShort
>> used for the triangles then you'll need just one of the associated
>> attribute for it.
>>
>> BIND_PER_PRIMITIVE will apply the attribute per primitive in you case
>> per triangle.
>>
>> Tex coords in the OSG are always bound per vertex, there isn't a
>> control to alter this.
>>
>> If you have a vertex array and indices for your triangles the natural
>> thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES)
>> then use push_back(tri.p1) for each index on each triangle.
>>
>> I would suggest binding the normals per vertex, you'll have to do this
>> for the tex coords as well.  If a single vertex will have multiple tex
>> coords or multiple normals associated with it due to differences in
>> the triangles then you'll need to duplicate the vertices and remap the
>> indices on the triangles to fit this.
>>
>> Robert.
>>
>> On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach
>>
>>  wrote:
>> > Thank you Paul for your response.
>> >
>> > Yes, you are right, the solution isn't perfect at all. But I'm
>> > integrating some external code which is just giving me a vertex array
>> > and a per triangle callback with vertex indexes and normal and texture
>> > coords.
>> >
>> > And further more I need some screenshots very urgently for a customer
>> > presentation.
>> >
>> > The performance improvement has to wait :-(
>> >
>> > So I try to analyse why it's not working. And I detected something I
>> > don't understand.
>> > In my opinion it should give the same result having:
>> > 1) one normal per triangle an binding PER_PRIMITIVE
>> > 2) 3 times the same normal and binding PER_PRIMITIVE_SET
>> >
>> > But it doesn't. So I'm confused.
>> >
>> > Thanks for further hints.
>> >
>> > - Werner -
>> >
>> > Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz:
>> >> Werner Modenbach wrote:
>> >> > Maybe someone can give me some explanation on my stupid little
>> >> > problem.
>> >> >
>> >> > I have a geometry being composed of TRIANGLES.
>> >> > I have a vertex-array, a verted-index-array and a normal-array
>> >> > assigned to my geometry.
>> >>
>> >> Off-topic: Do you need to use the vertex-index-array? It is deprecated:
>> >>          /** deprecated - forces OpenGL slow path, just kept for
>> >> backwards compatibility.*/
>> >>          void setVertexIndices(IndexArray* array);
>> >>
>> >> > 3 indexes and 3 normals per Triangle.
>> >> > Normal binding is set to BIND_PER_PRIMITIVE_SET.
>> >> >
>> >> > Unfortunately the rendering shows the geometry flat in curious dark
>> >> > colors and some unexpected light behaviour.
>> >> > For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE
>> >> > and pushed just 1 normal per TRIANGLE.
>> >> > Everything looks good except I see the triangles and the geometry
>> >> > isn't smooth.
>> >> > The next test is pushing the same normal vector 3 times and setting
>> >> > the binding back to BIND_PER_PRIMITI

Re: [osg-users] Issue with normal vectors

2010-08-26 Thread Brian R Hill
Just try this and see how it works:

geometry->setNormalBinding(osg::Geometry::BIND_PER_VERTEX);

Brian

This is a PRIVATE message. If you are not the intended recipient, please delete 
without copying and kindly advise us by e-mail of the mistake in delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any 
order or other contract unless pursuant to explicit written agreement or 
government initiative expressly permitting the use of e-mail for such purpose.
-osg-users-boun...@lists.openscenegraph.org wrote: -

To: OpenSceneGraph Users 
From: Werner Modenbach 
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/26/2010 07:08AM
Subject: Re: [osg-users] Issue with normal vectors

Thanks Robert, I get closer to it.

Just for verification:

If I have i.e. 10 vertexes and I get 20 calls to the callback method each 
defining a triangle.
Each call gives me 3 indexes, 3 normals and 3 texcoords.

Right now I just push everything into the corresponding arrays and at the end 
I call:
    geometry->addPrimitiveSet(new 
osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0, osgVertexIndices->size()));

You say this will not work because:
1) geometry->setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
    expects just 1 normal for the whole thing (?)
2) Texture coordinates are allways bound per vertex?

In this case I have to:
1) initialize a normal array with Vec3(0.0, 0.0, 0.0)
    for each triangle callback I have to look on each vertex index , if the
    indexes normal is 0
        if yes:  just set it
        if no:   duplicate the vertex at the end of the vertexes and push_back 
                   the normal
2) do something comparable on the texcoords

Is that your recommendation?

Is there any way to bind normals to the vertex indexes?

Thanks in advance!

- Werner -

Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield:
> Hi Werner,
> 
> 
> BIND_PER_PRIMITIVE_SET will mean that you'll have one of the
> associated attribute (i.e. colour, normal) per osg::PrimitiveSet
> attached the osg::Geometry, so if you have one osg::DrawElementsUShort
> used for the triangles then you'll need just one of the associated
> attribute for it.
> 
> BIND_PER_PRIMITIVE will apply the attribute per primitive in you case
> per triangle.
> 
> Tex coords in the OSG are always bound per vertex, there isn't a
> control to alter this.
> 
> If you have a vertex array and indices for your triangles the natural
> thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES)
> then use push_back(tri.p1) for each index on each triangle.
> 
> I would suggest binding the normals per vertex, you'll have to do this
> for the tex coords as well.  If a single vertex will have multiple tex
> coords or multiple normals associated with it due to differences in
> the triangles then you'll need to duplicate the vertices and remap the
> indices on the triangles to fit this.
> 
> Robert.
> 
> On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach
> 
>  wrote:
> > Thank you Paul for your response.
> > 
> > Yes, you are right, the solution isn't perfect at all. But I'm
> > integrating some external code which is just giving me a vertex array
> > and a per triangle callback with vertex indexes and normal and texture
> > coords.
> > 
> > And further more I need some screenshots very urgently for a customer
> > presentation.
> > 
> > The performance improvement has to wait :-(
> > 
> > So I try to analyse why it's not working. And I detected something I
> > don't understand.
> > In my opinion it should give the same result having:
> > 1) one normal per triangle an binding PER_PRIMITIVE
> > 2) 3 times the same normal and binding PER_PRIMITIVE_SET
> > 
> > But it doesn't. So I'm confused.
> > 
> > Thanks for further hints.
> > 
> > - Werner -
> > 
> > Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz:
> >> Werner Modenbach wrote:
> >> > Maybe someone can give me some explanation on my stupid little
> >> > problem.
> >> > 
> >> > I have a geometry being composed of TRIANGLES.
> >> > I have a vertex-array, a verted-index-array and a normal-array
> >> > assigned to my geometry.
> >> 
> >> Off-topic: Do you need to use the vertex-index-array? It is deprecated:
> >>          /** deprecated - forces OpenGL slow path, just kept for
> >> backwards compatibility.*/
> >>          void setVertexIndices(IndexArray* array);
> >> 
> >> > 3 indexes and 3 normals per Triangle.
> >> > Normal binding is set to BIND_PER_PRIMITIVE_SET.
> >> > 
> >> > Unfortunately the rendering shows the geometry flat in curious dark
> >> > colors and some unexpected light behaviour.
> >> > For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE
> >> > and pushed just 1 normal per TRIANGLE.
> >> > Everything looks good except I see the triangles and the geometry
> >> > isn't smooth.
> >> > The next test is pushing the same normal vector 3 times and setting
> >> > the binding back to BIND_PER_PRIMITIVE_SET.
> >> > In my und

Re: [osg-users] Issue with normal vectors

2010-08-26 Thread Werner Modenbach
Thanks Robert, I get closer to it.

Just for verification:

If I have i.e. 10 vertexes and I get 20 calls to the callback method each 
defining a triangle.
Each call gives me 3 indexes, 3 normals and 3 texcoords.

Right now I just push everything into the corresponding arrays and at the end 
I call:
geometry->addPrimitiveSet(new 
osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0, osgVertexIndices->size()));

You say this will not work because:
1) geometry->setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
expects just 1 normal for the whole thing (?)
2) Texture coordinates are allways bound per vertex?

In this case I have to:
1) initialize a normal array with Vec3(0.0, 0.0, 0.0)
for each triangle callback I have to look on each vertex index , if the
indexes normal is 0
if yes:  just set it
if no:   duplicate the vertex at the end of the vertexes and push_back 
   the normal
2) do something comparable on the texcoords

Is that your recommendation?

Is there any way to bind normals to the vertex indexes?

Thanks in advance!

- Werner -

Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield:
> Hi Werner,
> 
> 
> BIND_PER_PRIMITIVE_SET will mean that you'll have one of the
> associated attribute (i.e. colour, normal) per osg::PrimitiveSet
> attached the osg::Geometry, so if you have one osg::DrawElementsUShort
> used for the triangles then you'll need just one of the associated
> attribute for it.
> 
> BIND_PER_PRIMITIVE will apply the attribute per primitive in you case
> per triangle.
> 
> Tex coords in the OSG are always bound per vertex, there isn't a
> control to alter this.
> 
> If you have a vertex array and indices for your triangles the natural
> thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES)
> then use push_back(tri.p1) for each index on each triangle.
> 
> I would suggest binding the normals per vertex, you'll have to do this
> for the tex coords as well.  If a single vertex will have multiple tex
> coords or multiple normals associated with it due to differences in
> the triangles then you'll need to duplicate the vertices and remap the
> indices on the triangles to fit this.
> 
> Robert.
> 
> On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach
> 
>  wrote:
> > Thank you Paul for your response.
> > 
> > Yes, you are right, the solution isn't perfect at all. But I'm
> > integrating some external code which is just giving me a vertex array
> > and a per triangle callback with vertex indexes and normal and texture
> > coords.
> > 
> > And further more I need some screenshots very urgently for a customer
> > presentation.
> > 
> > The performance improvement has to wait :-(
> > 
> > So I try to analyse why it's not working. And I detected something I
> > don't understand.
> > In my opinion it should give the same result having:
> > 1) one normal per triangle an binding PER_PRIMITIVE
> > 2) 3 times the same normal and binding PER_PRIMITIVE_SET
> > 
> > But it doesn't. So I'm confused.
> > 
> > Thanks for further hints.
> > 
> > - Werner -
> > 
> > Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz:
> >> Werner Modenbach wrote:
> >> > Maybe someone can give me some explanation on my stupid little
> >> > problem.
> >> > 
> >> > I have a geometry being composed of TRIANGLES.
> >> > I have a vertex-array, a verted-index-array and a normal-array
> >> > assigned to my geometry.
> >> 
> >> Off-topic: Do you need to use the vertex-index-array? It is deprecated:
> >>  /** deprecated - forces OpenGL slow path, just kept for
> >> backwards compatibility.*/
> >>  void setVertexIndices(IndexArray* array);
> >> 
> >> > 3 indexes and 3 normals per Triangle.
> >> > Normal binding is set to BIND_PER_PRIMITIVE_SET.
> >> > 
> >> > Unfortunately the rendering shows the geometry flat in curious dark
> >> > colors and some unexpected light behaviour.
> >> > For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE
> >> > and pushed just 1 normal per TRIANGLE.
> >> > Everything looks good except I see the triangles and the geometry
> >> > isn't smooth.
> >> > The next test is pushing the same normal vector 3 times and setting
> >> > the binding back to BIND_PER_PRIMITIVE_SET.
> >> > In my understanding this should give the same optical result as
> >> > before. Unfortunately it doesn't and everything is dark again.
> >> > 
> >> > I guess, I misunderstand something with the normal bindings.
> >> > 
> >> > Any hint is highly appreciated. Thanks in advance
> >> 
> >> I'm not sure why you don't use BIND_PER_VERTEX, as you stated above that
> >> your normal array contains 3 normals per triangle, so you have one
> >> normal per vertex, right?
> >> 
> >> BIND_PER_PRIMITIVE would result in flat shading (only one normal used
> >> for each triangle -- which, by the way, also forces OpenGL down the
> >> slow path), and BIND_PER_PRIMITIVE_SET would be even more granular: one
> >> normal used for each PrimitiveSet you add to t

Re: [osg-users] Can we used OSG for ES 2.0 project on linux??

2010-08-26 Thread Rakesh Parmar
Hi bouffa,

Now its compiling .Thanks a lot.

Regards,
RK>

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=31065#31065





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Issue with normal vectors

2010-08-26 Thread Robert Osfield
Hi Werner,


BIND_PER_PRIMITIVE_SET will mean that you'll have one of the
associated attribute (i.e. colour, normal) per osg::PrimitiveSet
attached the osg::Geometry, so if you have one osg::DrawElementsUShort
used for the triangles then you'll need just one of the associated
attribute for it.

BIND_PER_PRIMITIVE will apply the attribute per primitive in you case
per triangle.

Tex coords in the OSG are always bound per vertex, there isn't a
control to alter this.

If you have a vertex array and indices for your triangles the natural
thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES)
then use push_back(tri.p1) for each index on each triangle.

I would suggest binding the normals per vertex, you'll have to do this
for the tex coords as well.  If a single vertex will have multiple tex
coords or multiple normals associated with it due to differences in
the triangles then you'll need to duplicate the vertices and remap the
indices on the triangles to fit this.

Robert.

On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach
 wrote:
> Thank you Paul for your response.
>
> Yes, you are right, the solution isn't perfect at all. But I'm integrating
> some external code which is just giving me a vertex array and a per triangle
> callback with vertex indexes and normal and texture coords.
>
> And further more I need some screenshots very urgently for a customer
> presentation.
>
> The performance improvement has to wait :-(
>
> So I try to analyse why it's not working. And I detected something I don't
> understand.
> In my opinion it should give the same result having:
> 1) one normal per triangle an binding PER_PRIMITIVE
> 2) 3 times the same normal and binding PER_PRIMITIVE_SET
>
> But it doesn't. So I'm confused.
>
> Thanks for further hints.
>
> - Werner -
>
>
> Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz:
>> Werner Modenbach wrote:
>> > Maybe someone can give me some explanation on my stupid little problem.
>> >
>> > I have a geometry being composed of TRIANGLES.
>> > I have a vertex-array, a verted-index-array and a normal-array assigned
>> > to my geometry.
>>
>> Off-topic: Do you need to use the vertex-index-array? It is deprecated:
>>          /** deprecated - forces OpenGL slow path, just kept for backwards
>> compatibility.*/
>>          void setVertexIndices(IndexArray* array);
>>
>> > 3 indexes and 3 normals per Triangle.
>> > Normal binding is set to BIND_PER_PRIMITIVE_SET.
>> >
>> > Unfortunately the rendering shows the geometry flat in curious dark
>> > colors and some unexpected light behaviour.
>> > For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE and
>> > pushed just 1 normal per TRIANGLE.
>> > Everything looks good except I see the triangles and the geometry isn't
>> > smooth.
>> > The next test is pushing the same normal vector 3 times and setting the
>> > binding back to BIND_PER_PRIMITIVE_SET.
>> > In my understanding this should give the same optical result as before.
>> > Unfortunately it doesn't and everything is dark again.
>> >
>> > I guess, I misunderstand something with the normal bindings.
>> >
>> > Any hint is highly appreciated. Thanks in advance
>>
>> I'm not sure why you don't use BIND_PER_VERTEX, as you stated above that
>> your normal array contains 3 normals per triangle, so you have one normal
>> per vertex, right?
>>
>> BIND_PER_PRIMITIVE would result in flat shading (only one normal used for
>> each triangle -- which, by the way, also forces OpenGL down the slow
>> path), and BIND_PER_PRIMITIVE_SET would be even more granular: one normal
>> used for each PrimitiveSet you add to the Geometry. This would make all
>> triangles in the PrimitiveSet either uniformly dark or uniformly lit,
>> depending on the direction of the one normal used for the whole group.
>>
>> For analysis purposes, I suggest using the normals pseudoloader:
>>    > osgviewer dumptruck.osg.normals
>>
>> Hope that helps,
>>     -Paul
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> --
> TEXION Software Solutions
>
> TEXION GmbH -  Rotter Bruch 26a  -  D 52068 Aachen - HRB 14999 Aachen
> Fon: +49 241 475757-0, Fax: +49 241 475757-29, web: http://www.texion.eu
>
> Geschäftsführer/Managing Director: Werner Modenbach
> ___
> 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] Issue with normal vectors

2010-08-26 Thread Werner Modenbach
Thank you Paul for your response.

Yes, you are right, the solution isn't perfect at all. But I'm integrating 
some external code which is just giving me a vertex array and a per triangle 
callback with vertex indexes and normal and texture coords.

And further more I need some screenshots very urgently for a customer 
presentation.

The performance improvement has to wait :-(

So I try to analyse why it's not working. And I detected something I don't 
understand.
In my opinion it should give the same result having:
1) one normal per triangle an binding PER_PRIMITIVE
2) 3 times the same normal and binding PER_PRIMITIVE_SET

But it doesn't. So I'm confused.

Thanks for further hints.

- Werner -


Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz:
> Werner Modenbach wrote:
> > Maybe someone can give me some explanation on my stupid little problem.
> > 
> > I have a geometry being composed of TRIANGLES.
> > I have a vertex-array, a verted-index-array and a normal-array assigned
> > to my geometry.
> 
> Off-topic: Do you need to use the vertex-index-array? It is deprecated:
>  /** deprecated - forces OpenGL slow path, just kept for backwards
> compatibility.*/
>  void setVertexIndices(IndexArray* array);
> 
> > 3 indexes and 3 normals per Triangle.
> > Normal binding is set to BIND_PER_PRIMITIVE_SET.
> > 
> > Unfortunately the rendering shows the geometry flat in curious dark
> > colors and some unexpected light behaviour.
> > For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE and
> > pushed just 1 normal per TRIANGLE.
> > Everything looks good except I see the triangles and the geometry isn't
> > smooth.
> > The next test is pushing the same normal vector 3 times and setting the
> > binding back to BIND_PER_PRIMITIVE_SET.
> > In my understanding this should give the same optical result as before.
> > Unfortunately it doesn't and everything is dark again.
> > 
> > I guess, I misunderstand something with the normal bindings.
> > 
> > Any hint is highly appreciated. Thanks in advance
> 
> I'm not sure why you don't use BIND_PER_VERTEX, as you stated above that
> your normal array contains 3 normals per triangle, so you have one normal
> per vertex, right?
> 
> BIND_PER_PRIMITIVE would result in flat shading (only one normal used for
> each triangle -- which, by the way, also forces OpenGL down the slow
> path), and BIND_PER_PRIMITIVE_SET would be even more granular: one normal
> used for each PrimitiveSet you add to the Geometry. This would make all
> triangles in the PrimitiveSet either uniformly dark or uniformly lit,
> depending on the direction of the one normal used for the whole group.
> 
> For analysis purposes, I suggest using the normals pseudoloader:
>> osgviewer dumptruck.osg.normals
> 
> Hope that helps,
> -Paul
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
TEXION Software Solutions

TEXION GmbH -  Rotter Bruch 26a  -  D 52068 Aachen - HRB 14999 Aachen
Fon: +49 241 475757-0, Fax: +49 241 475757-29, web: http://www.texion.eu

Geschäftsführer/Managing Director: Werner Modenbach
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] particle system FIX

2010-08-26 Thread Maxim Gammer
The problem with the system of particles:

in hiding the particle system and their subsequent screening creates a huge
number of particles (splash). But more than the big time difference between
concealment and display. The drawings depicted such a situation.

http://i35.tinypic.com/ridkhu.jpg
http://i33.tinypic.com/2nulhfd.jpg

The first figure shows the correct image, the second figure shows the
erroneous operation of the system of particles.

In addition, when a large number of particles occurs following warning:
Warning: State:: drawQuads (0, 72588) too large handle in remapping to
ushort glDrawElements.
Warning: State:: drawQuads (0, 72592) too large handle in remapping to
ushort glDrawElements.
Warning: State:: drawQuads (0, 72592) too large handle in remapping to
ushort glDrawElements.
Warning: State:: drawQuads (0, 72596) too large handle in remapping to
ushort glDrawElements.

fix this problem :


 inline int RandomRateCounter::numParticlesToCreate(double dt) const
{
_np += dt * getRateRange().get_random();
int n = static_cast(_np);
_np -= n;
*if (n > getRateRange().maximum) *
* **{*
* **n = getRateRange().get_random(); //or .get_random *
* **_np=0;*
* **}*
return n;
}


in attached file


-- 
Maxim Gammer


RandomRateCounter
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org