Re: [osg-users] How can I get last frame time inn order to create indepent FPS aniamtions?
Hi Ricardo,
Why don't try reference time?
viewer.getFrameStamp()->getReferenceTime();
Rafa.
On Mon, Nov 23, 2009 at 1:29 AM, Ricardo Ruiz wrote:
> Hi all.
>
> How can I get last frame time inn order to create indepent FPS aniamtions?
>
> For instance, something like m_last_time_frame:
>
>
>
> Code:
>
> double angle=0;
> while (!viewer.done()) {
> angle=angle+0.1*m_last_time_frame;
>
> viewer.getCamera()->setViewMatrixAsLookAt(osg::Vec3(0,-400,150),
> osg::Vec3(0,0,0), osg::Vec3(0,0,1));
>
> viewer.getCamera()->setViewMatrix(osg::Matrix::rotate(angle*DEG_TO_RAD,0,0,1)*viewer.getCamera()->getViewMatrix());
> viewer.frame();
> }
>
>
>
>
> Thanks.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=20102#20102
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
Rafael Gaitán Linares
Instituto de Automática e Informática Industrial http://www.ai2.upv.es
Ciudad Politécnica de la Innovación
Universidad Politécnica de Valencia
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Develop a scalable binary file format for native OSG scenes?
Hi Robert
> A couple of quick thoughts. I would love to replace the .osg and .ive
> formats with a new single native binary/ascii format. Would it be
> possible to do both with a single plugin?
It's not hard to support both binary and ascii format, I think. In the
case of mine, just leave user-defined wrappers alone and modify only
the read*()/write*() functions like this:
void writeCharArray( const char* s, unsigned int size )
{
if ( _isBinary )
_out->write(s, size);
else
_out << s;
}
But it won't be easy to make a friendly one. For example, cow.osg
includes these lines:
StateSet {
rendering_hint OPAQUE_BIN
renderBinMode INHERIT
GL_CULL_FACE OFF
GL_LIGHTING ON
}
With the new plugin, which lacks enum descriptions, it may come like:
StateSet {
rendering_hint 1
renderBinMode 8
2884 0
2896 1
}
Hardly to realize it unless you are very familiar with OSG and OpenGL
(GL_CULL_FACE=0x0B44 and GL_LIGHTING=0x0B50). And it really will be a
pain if we had to modify each wrapper to comvert enums to strings.
> The extension .osg would be the appropriate thing for a native .osg
> format. An appropriate header could say which version of is
> represented in the file. Perhaps a .osgb could be used for a binary
> if needed.
As Paul said, .osgb may be already used. I suggest .oa for ascii files
and .ob for binary ones, or .osgs (osg scene) for both. Any more
ideas? :)
> In VirtualPlanetBuilder I experimented with serialization of class
> members using a series of templated classes to bind the reading and
> writing of members. Perhaps something similar could be used - perhaps
> you already use such an approach, tomorrow I should have chance to
> review your code.
I just took a review of osgDB::Serializer and related classes. They
use osgDB::Output and Input for I/O operations. In fact I've leart
into these two classes before, attempting to make them work both
'asciily' and 'binarily'. But the heavy workload forces me to give up
at this stage. Maybe we could have a plan of rewriting osgDB::Output
and Input classes, and then benefit from existing Serializer? Instead
of developing a totally new series of serialization classes.
> I also do wonder about whether osgIntrospection could be used to help
> fill out the serialization details, or... perhaps even the reverse,
> have the plugin specify accessors to the class members to provide a
> form of introspection... and then osgIntrospection could then be
> deprecated...
Sorry to say, I've no idea about this at present. :)
Wang Rui
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Running VPBMaster
So I had VPBMaster running for over two days and it didn't seem to be doing
anything so I used Ctrl+C to cancel the task and the following was output to
the screen:
"
Recieved signal 2, doing TERMINATE_RUNNING_TASKS_THEN_EXIT.
MachinePool::signal(2)
Machine::signal(2)
Machine::cancelThreads() hostname= , threads=2
Cancel thread
Cancel thread
Completed Machine::cancelThreads() hostname= , threads=2
End of TaskSet: tasksPending=4113 taskCompleted=0 taskRunning=0 tasksFailed=0
Continuing with existing TaskSet.
End of Run: tasksPending=4113 taskCompleted=0 taskRunning=0 tasksFailed=0
MachinePool::reportTimingStats()
Machine :
Task::type='' minTime=1.120172 maxTime=1.122734 averageTime=1.121453
totalComputeTime=2.242906 numTasks=2
Finished run, but did not complete 4113 tasks.
Total elapsed time = 191483.915636
"
The total elapsed time equates to 2.2 days, which is about how long it was
running before I cancelled it. Can anyone tell me what it was doing for 2.2
days, if no tasks were completed in that time? I kicked it off again and
cancelled it and I had the same number of tasks created, with all of them
Pending, and nothing completing. Am I missing a piece of the puzzle here. Can
anyone please help me?
Thanks,
Jake
From: jaco...@hotmail.com
To: osg-users@lists.openscenegraph.org
Date: Sun, 22 Nov 2009 19:02:07 -0500
Subject: Re: [osg-users] Running VPBMaster
Any suggestions here? Should I be doing something with the .source file?
From: jaco...@hotmail.com
To: osg-users@lists.openscenegraph.org
Date: Fri, 20 Nov 2009 15:36:05 -0500
Subject: [osg-users] Running VPBMaster
Alright, it looks like I've finally gotten VPBMaster-0.9.10 up and running
(with OSG-2.8.0) and I attempted to feed it the input I was previously trying
to feed to OSGDem with my older version of OSG. It spit a lot of text to the
screen, and now seems to have hung. The last thing on the screen is "scheduling
task : tasks/build_subtile_L3_X3_Y3/build_subtile_L7_X63_Y63.task". I tried
pressing ENTER and it didn't do anything.
I've noticed that I now have a couple new files: build_master.source (0 kb) and
build_master.tasks (284 kb). I've also got a new "tasks" directory, which has
17 files ("build_root_L0_X0_Y0.task" and
"build_subtile_L3_X0_Y0.task"-"build_subtile_L3_X3_Y3.task") and 16 directories
("build_subtile_L3_X0_Y0"-"build_subtile_L3_X3_Y3", each consisting of 256
files). Do I need to do something next, or is it processing something behind
the curtain, or did something go wrong since my .source file is 0 kb? Any help
is appreciated!
Thanks,
Jake
Windows 7: It works the way you want. Learn more.
Hotmail: Trusted email with powerful SPAM protection. Sign up now.
_
Windows 7: I wanted simpler, now it's simpler. I'm a rock star.
http://www.microsoft.com/Windows/windows-7/default.aspx?h=myidea?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_myidea:112009___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How can I get last frame time inn order to create indepent FPS aniamtions?
Hi all.
How can I get last frame time inn order to create indepent FPS aniamtions?
For instance, something like m_last_time_frame:
Code:
double angle=0;
while (!viewer.done()) {
angle=angle+0.1*m_last_time_frame;
viewer.getCamera()->setViewMatrixAsLookAt(osg::Vec3(0,-400,150),
osg::Vec3(0,0,0), osg::Vec3(0,0,1));
viewer.getCamera()->setViewMatrix(osg::Matrix::rotate(angle*DEG_TO_RAD,0,0,1)*viewer.getCamera()->getViewMatrix());
viewer.frame();
}
Thanks.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20102#20102
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Running VPBMaster
Any suggestions here? Should I be doing something with the .source file?
From: jaco...@hotmail.com
To: osg-users@lists.openscenegraph.org
Date: Fri, 20 Nov 2009 15:36:05 -0500
Subject: [osg-users] Running VPBMaster
Alright, it looks like I've finally gotten VPBMaster-0.9.10 up and running
(with OSG-2.8.0) and I attempted to feed it the input I was previously trying
to feed to OSGDem with my older version of OSG. It spit a lot of text to the
screen, and now seems to have hung. The last thing on the screen is "scheduling
task : tasks/build_subtile_L3_X3_Y3/build_subtile_L7_X63_Y63.task". I tried
pressing ENTER and it didn't do anything.
I've noticed that I now have a couple new files: build_master.source (0 kb) and
build_master.tasks (284 kb). I've also got a new "tasks" directory, which has
17 files ("build_root_L0_X0_Y0.task" and
"build_subtile_L3_X0_Y0.task"-"build_subtile_L3_X3_Y3.task") and 16 directories
("build_subtile_L3_X0_Y0"-"build_subtile_L3_X3_Y3", each consisting of 256
files). Do I need to do something next, or is it processing something behind
the curtain, or did something go wrong since my .source file is 0 kb? Any help
is appreciated!
Thanks,
Jake
Windows 7: It works the way you want. Learn more.
_
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141665/direct/01/___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple cameras with setRenderOrder(PRE_RENDER, i)
Ross Bohner wrote: Hi, Thank you for the code snippet. Looking it over I see two differences from my implementation which have been giving me a headache. These are not necessarily related to camera render orders so it might be appropriate to send these as separate threads. First difference from your code and mine is the lack of you needing to allocate an image to the render in order to place the texture within a stateset: Consider the following OpenGL call: glTexImage2D(..., width, height, ..., NULL ); Note I'm passing in a width and height but no data. According to the OpenGL spec, this allocates an undefined texture image with dimensions width x height. This is essentially what my posted example is causing to happen when I create an osg::Texture2D with width and height, but no osg::Image data. I don't care that the texture is undefined, because my app initializes it in the first render pass. In my experience, this is required or else a seg fault occurs when the draw traversal references "_texture". I am confused on how you are able to pass the texture without allocating an image inside the texture. I have included a code snippet below to fully clarify what I see occurring. Try my code; if it segfaults, let me know. :-) The second difference is your code uses non power of 2 dimensions for your texture to be rendered by your camera. Whenever I have tried to do this I have run into the error : "Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,)" during every draw call to the geometry containing the texture Wow. GLView shows that even the old GeForce 6xxx series supports the NPOT extension. Do you have really old hardware, or perhaps you haven't updated your driver recently? Your code is incomplete so it's impossible to tell what you're doing. You have a pre-render camera with a texture attached; you also have a Geode to render a textured primitive. But I don't see how your code adds them to a scene graph. Nor do I see anything added to your pre-render camera, so as far as I can see there is nothing for it to render. Have you tried compiling and running the code I sent you? How about the osgprerender example? (osgprerender is a little complex, which is why I wrote the more concise rtt.cpp example that I posted.) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Develop a scalable binary file format for native OSG scenes?
I love the idea of an extensible binary format. Good work.
Robert Osfield wrote:
The extension .osg would be the appropriate thing for a native .osg
format. An appropriate header could say which version of is
represented in the file. Perhaps a .osgb could be used for a binary
if needed.
I'd recommend using a new unique extension for a new format, unless
someone wants to take responsibility to fix OSG's plugin mechanism so
that it is more robust in the presence of different formats using the
same extension. See the thread "Plugin extension registry" from last
June for a summary of the issue.
Both ".osg" and ".osgb" are presently in use (".osgb" is the file format
used by the osgBullet project at Google Code).
-Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer windows build is broken
Robert Osfield schrieb: Hi Oleg, On Sun, Nov 22, 2009 at 10:38 AM, Oleg Dedkow wrote: The current trunk version of "GraphicsWindowWin32" (as of today) cannot be compiled under Windows, since the "HGLRC createContextImplementation()" method declaration is missing in the corresponding header file. After adding it the "osgViewer" library compiles without any problems. Argg... mixing submission makes life complicated... I've just spotted the error and checked in the missing header. What I don't understand is how last nights build under Windows succeeded given this error Robert. Embedded AI, another time/space continuum or just a little help of Q :-) Oleg ___ 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] Shadows on two-sided polygons
Hi Andreas, thanks a lot for your detailed answer. I will work through the example within one of the next holydays, as I am not a professional programmer (I´m a math teacher) and will need some quiet time for a demanding task like this. My software is a math-software to illustrate vector geometry, and thus displays planes and so on simply as polygons. That´s the reason I need two-sided materials (or at least I decided to do so, the alternative would have been to use more massive planes). For the time being it is a comfort for me that I didn´t make a simple mistake and that it is quite some work to adjust the StandardShadowMap to two-sided polygons. Well... it depends. If the only trouble is incorrect back face lighting and lack of shadows from faces in front of light, then method could be simpler: 1. You can write your own shaders. I have read you already did that for ShadowMap. Then with small modification you could try using them with StandardShadowMap. This would give you the correct lighting I guess. Warning: if you want to adapt shaders made for ShadowMap make sure you change names of uniforms to match names used by StandardShadowMap (they use different naming convention). 2. To make sure both faces cast shadows simply call setMode( GL_CULL_FACE, OFF | OVERRIDE ) on your scene root stateset. This will force usage of both faces in shadow map rendering. I hope this will let you reach the goal. But if you don't expect to use any more complex - view dependent techniques in the future then it would be easier to stay with ShadowMap. StandardShadowMap gives the same shadow precision. When one asks why there are two techniques doing the same then the answer is that StandardShadowMap lays foundation for more advanced techniques like MinimalShadowMap & LispSM variants. So, if one day you decide to switch to LispSM or MinimalXXXShadowMap then migration will be definitely simpler when you make your tweaks for StandardShadowMap. Who maintains ShadowMap? I´d like the maintainer to do some tests with my shader. If you think it´s better than the standard one, I´ll refactor it into the Shadow-Map code. For a first impression, see the images in the last mail. I guess that would be Robert. If you post the fixes on submissions lists all interested may work as your testers. Regards & thanks for the example, You're welcome. Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] createContextImplementation is undefined in GraphicsWindowWin32.cpp
Hi Robert, Thank you for taking the time to reply. Your guess was correct, updating again fixed my build. Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20092#20092 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Develop a scalable binary file format for native OSG scenes?
Hi Wang Rui, I haven't done a review yet, so can't comment on specifics of the design/implementation. A couple of quick thoughts. I would love to replace the .osg and .ive formats with a new single native binary/ascii format. Would it be possible to do both with a single plugin? The extension .osg would be the appropriate thing for a native .osg format. An appropriate header could say which version of is represented in the file. Perhaps a .osgb could be used for a binary if needed. In VirtualPlanetBuilder I experimented with serialization of class members using a series of templated classes to bind the reading and writing of members. Perhaps something similar could be used - perhaps you already use such an approach, tomorrow I should have chance to review your code. I also do wonder about whether osgIntrospection could be used to help fill out the serialization details, or... perhaps even the reverse, have the plugin specify accessors to the class members to provide a form of introspection... and then osgIntrospection could then be deprecated... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture wrapping for a geometry object
Hi Dominc,
I don't know where you might have got the impression that you can't
set up texture repeats with geometry - you just using texture
coordinates beyond the 0.0 to 1.0 range and you'll get repeats.
Another way is to use a texture matrix to up the tex coords from 0.0
to 1.0 range to what you want.
Robert.
On Sun, Nov 22, 2009 at 3:28 PM, Dominic Stalder
wrote:
> Hi there
>
> I would like to wrap (repeated) my texture image on a geometry object. I
> read somewhere, that this is not possible directly on the geometry, but how
> can I do it otherwise? Here is my code:
>
> /*
> * creates the ground geometry
> */
> // creates the vertices array
> ref_ptr verticesGround = new Vec3Array;
> verticesGround->push_back(Vec3(-WORLD_INFINITY, 0.0, -WORLD_INFINITY)); //
> back left
> verticesGround->push_back(Vec3(WORLD_INFINITY, 0.0, -WORLD_INFINITY)); //
> back right
> verticesGround->push_back(Vec3(WORLD_INFINITY, 0.0, WORLD_INFINITY)); //
> front right
> verticesGround->push_back(Vec3(-WORLD_INFINITY, 0.0, WORLD_INFINITY)); //
> front left
> // creates the normal array
> ref_ptr normalsGround = new Vec3Array;
> normalsGround->push_back(Vec3(0.0, 1.0, 0.0));
> // creates the texture coordinates array
> ref_ptr texCoordGround = new Vec2Array;
> texCoordGround->push_back(Vec2(0.0, 0.0));
> texCoordGround->push_back(Vec2(1.0, 0.0));
> texCoordGround->push_back(Vec2(1.0, 1.0));
> texCoordGround->push_back(Vec2(0.0, 1.0));
> // loads the texture image
> ref_ptr imgGrass =
> osgDB::readImageFile(Utilities::filePath("res/osg/grass.png").toStdString());
> // attaches the image to the texture
> ref_ptr texGround = new Texture2D;
> texGround->setDataVariance(Object::DYNAMIC);
> texGround->setWrap(Texture::WRAP_S, Texture::REPEAT);
> texGround->setWrap(Texture::WRAP_T, Texture::REPEAT);
> texGround->setImage(imgGrass.get());
> // releases the image after applying
> texGround->setUnRefImageDataAfterApply(true);
> // creates the geometry
> ref_ptr geomGround = new Geometry;
> geomGround->setVertexArray(verticesGround.get());
> geomGround->setNormalArray(normalsGround.get());
> geomGround->setTexCoordArray(0, texCoordGround.get());
>
> // adds the primitive set to the geometry
> geomGround->addPrimitiveSet(new DrawArrays(PrimitiveSet::QUADS, 0, 4));
> // enables all the necessary states for the ground geometry node
> ref_ptr stateGroundGeometry = geomGround->getOrCreateStateSet();
> stateGroundGeometry->setTextureAttributeAndModes(0, texGround.get(),
> StateAttribute::ON);
>
> // creates the geode
> ref_ptr geoGround = new Geode;
> geoGround->addDrawable(geomGround.get());
>
> Thanks a lot in advance!
>
> Best regards
> Dominic
> ___
> 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] osgViewer windows build is broken
Hi Oleg, On Sun, Nov 22, 2009 at 10:38 AM, Oleg Dedkow wrote: > The current trunk version of "GraphicsWindowWin32" (as of today) cannot be > compiled under Windows, since the "HGLRC createContextImplementation()" > method declaration is missing in the corresponding header file. After adding > it the "osgViewer" library compiles without any problems. Argg... mixing submission makes life complicated... I've just spotted the error and checked in the missing header. What I don't understand is how last nights build under Windows succeeded given this error Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] createContextImplementation is undefined in GraphicsWindowWin32.cpp
Hi John, Could you try updating again, it could be that you just updated between check-ins. I just checked cdash.openscenegraph.org and it looks to me like the Windows build machine build OK last night so things should be OK. Robert. On Sat, Nov 21, 2009 at 10:04 PM, John Price wrote: > Hi, > > Trying to build SVN 10813 update fails because osgViewer won't compile on > Windows. GraphicsWindowWin32.cpp fails because createContextImplementation is > undefined. > > I have the entire source tree indexed, and doing a full text search finds > only one reference to createContextImplementation, and that is in > GraphicsWindowWin32.cpp on line 1198. > > Thank you! > > Cheers, > John > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=20068#20068 > > > > > > ___ > 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] Develop a scalable binary file format for native OSG scenes?
Hi Wang, Just a little thing to say: I love your idea! I don't have time to look at it right now, but I'm sure I'll use that format later. Thanks. -- Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sun, 22 Nov 2009 12:10:21 +0100, Wang Rui a écrit: Hi Robert and all, I'd like to introduce my work of developing a new scalable binary reader/writer plugin in the past a few weeks. It took me more than half a month coding and doing some simple tests. And I really wish it be a good supplement of current native osg scene formats (.osg and .ive), or furthermore, a possible replacement of the .ive format in future? As we know before, the popular used .ive format has been not extensible from the very beginning. So core developers should always update osgdb_ive itself to add new classes and features. And user-defined nodes and objects can only be stored in a customized file format, or using the .osg plugin supporting a DotOsgWrapper mechanism instead, which is scalable. I decided to mimic this DotOsgWrapper mechanism and try to implement a binary file format (.osg is text format and seems to be hardly to work binarily). And I finally created a preliminary version. Because of the size limitation of our mail list, I have to put the source code tarball on my project site and provide the download link here: http://osgenginebook.googlecode.com/files/osgdb_bin.tar.gz Copy the extracted directory to your osgPlugins location and edit osgPlugins/CMakeLists.txt and add: ADD_SUBDIRECTORY(bin) In the ObjectWrapper header file, I have the ObjectWrapper class mimic osgDB::DotOsgWrapper, and the ObjectRegistry class which work like osgDB::Registry and maintains the wrapper map. The REGISTER_OBJECT_WRAPPER macro is used to declare a new object wrapper, which acts similar with REGISTER_DOTOSGWRAPPER. The InputStream and OutputStream class are use for read/write the OSG scene, which support different read*()/write*() methods. They also both have a shared object-id map, to avoid rereading/rewriting shared nodes and statesets. readObject()/writeObject() is the core function for reading/writing osg native subgraphs. The basic structure of this file format is: | offset |type | contents | 00h | uint | OSG verity value, low | 04h | uint | OSG verity value, high | 08h | uint | Plugin version | 0ch | uint | File attribtues | 10h | uint | Size of author information text | 14h | str | n-sized author information text |14h+n | uint | Size of root node wrapper name |18h+n | str | Root node wrapper name, e.g. "osg::Group" |...| uint | node id, non-zero value for shared objects |...| int | Size of written contents, used to vertify data |...| ...| Attributes of this object and its parent classes. |...| ...| ... The second step is to write wrappers for every osg core class. An example is: REGISTER_OBJECT_WRAPPER( Geode ) ( new osg::Geode, "osg::Geode", "osg::Object osg::Node osg::Geode", &readGeode, &writeGeode ); Hope you already find that there are few differences between it and the .osg wrappers. You will need to declare the proto, the wrapper's name, its associates (parent wrappers path) and reader/writer functions. Wrappers may be added to meet the extensibility requirements. To update existent wrappers, just append to the read/write functions. It should still be recognized by the old plugin, because of the vertify bits (see the format table). I also developed some initial options for writing with this plugin: - IncludeImageData: Set to save data of osg::Image objects directly. - IncludeImageFile: Set to save image files into this binary file. - UseExternalImage: Set to keep a reference of the image file name only. - WriteImageToFile: Set to write the image data on disk while saving. - AuthorInformation=... : Write author information into the binary file. The core OSG library classes are already finished and included in the wrapper_osg directory, but still not tested enough at present. These are on the TODO list right now, any advices and thoughts will be appreciated: - Decide the extension name: At present I just name it ".bin", short for "binary". A little naive and too common, isn't it? :D - Finish all wrappers of other core libraries, osgAnimation, osgText, osgWidgets and so on. These may be defined inside this plugin or use external dynamic libraries (like the osgwrapper_* files). - Automatically load external wrapper libraries: It would be easy to finish if we merge ObjectRegistry and osgDB::Registry and rewrite the findWrapper() function. - Packing algorithms for vectices and double values, which will be of high performance with geometries and heightfields. - Compression of the entire file, maybe zlib would still be the first choice? - COMPLETELY tests and bug fixes of the plugin, if it is ready to be merged into the osg trunk and be put into use. I'm looking forward to suggestions and tes
[osg-users] Texture wrapping for a geometry object
Hi there
I would like to wrap (repeated) my texture image on a geometry object. I
read somewhere, that this is not possible directly on the geometry, but
how can I do it otherwise? Here is my code:
/*
* creates the ground geometry
*/
// creates the vertices array
ref_ptr verticesGround = new Vec3Array;
verticesGround->push_back(Vec3(-WORLD_INFINITY, 0.0,
-WORLD_INFINITY)); // back left
verticesGround->push_back(Vec3(WORLD_INFINITY, 0.0,
-WORLD_INFINITY)); // back right
verticesGround->push_back(Vec3(WORLD_INFINITY, 0.0,
WORLD_INFINITY)); // front right
verticesGround->push_back(Vec3(-WORLD_INFINITY, 0.0,
WORLD_INFINITY)); // front left
// creates the normal array
ref_ptr normalsGround = new Vec3Array;
normalsGround->push_back(Vec3(0.0, 1.0, 0.0));
// creates the texture coordinates array
ref_ptr texCoordGround = new Vec2Array;
texCoordGround->push_back(Vec2(0.0, 0.0));
texCoordGround->push_back(Vec2(1.0, 0.0));
texCoordGround->push_back(Vec2(1.0, 1.0));
texCoordGround->push_back(Vec2(0.0, 1.0));
// loads the texture image
ref_ptr imgGrass =
osgDB::readImageFile(Utilities::filePath("res/osg/grass.png").toStdString());
// attaches the image to the texture
ref_ptr texGround = new Texture2D;
texGround->setDataVariance(Object::DYNAMIC);
texGround->setWrap(Texture::WRAP_S, Texture::REPEAT);
texGround->setWrap(Texture::WRAP_T, Texture::REPEAT);
texGround->setImage(imgGrass.get());
// releases the image after applying
texGround->setUnRefImageDataAfterApply(true);
// creates the geometry
ref_ptr geomGround = new Geometry;
geomGround->setVertexArray(verticesGround.get());
geomGround->setNormalArray(normalsGround.get());
geomGround->setTexCoordArray(0, texCoordGround.get());
// adds the primitive set to the geometry
geomGround->addPrimitiveSet(new DrawArrays(PrimitiveSet::QUADS, 0, 4));
// enables all the necessary states for the ground geometry node
ref_ptr stateGroundGeometry =
geomGround->getOrCreateStateSet();
stateGroundGeometry->setTextureAttributeAndModes(0, texGround.get(),
StateAttribute::ON);
// creates the geode
ref_ptr geoGround = new Geode;
geoGround->addDrawable(geomGround.get());
Thanks a lot in advance!
Best regards
Dominic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG Forum image attachments
Hi Art, I don't know if you caught the thread where this was mentioned, but it appears that any image attachments sent from the forum to the list go through a fugly filter, making it really small and reducing the colour depth quite dramatically. I presume that it's done to prevent huge images being sent off in bulk around the world clogging up inboxes, but is there any chance you could tweak it so that at least the colour depth is preserved? otherwise it makes it really hard to see what's in the image... ...plus I miss all the pretty pictures :) Cheers, Kim. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Does anybody know how to include OSGViewer using MFC?
Hi, There is an example called osgViewerMFC that may help you. You need to check the "BUILD_MFC_EXAMPLE" option in CMake. On Sat, Nov 21, 2009 at 7:28 AM, SoDong Jang wrote: > I`m trying to make a very simple CAD program but, all examples aren`t based > on MFC... > > I`ve seen the example called OSGMFC, but,, I couldn`t find an OSGViewer. > > As u see, I don`t know even the first thing of OSG. > > I want to follow sb`s achievement. > > BUT NO EXAMPLES.. help me... > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=20045#20045 > > > > > ___ > 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] Develop a scalable binary file format for native OSG scenes?
Hi Robert and all, I'd like to introduce my work of developing a new scalable binary reader/writer plugin in the past a few weeks. It took me more than half a month coding and doing some simple tests. And I really wish it be a good supplement of current native osg scene formats (.osg and .ive), or furthermore, a possible replacement of the .ive format in future? As we know before, the popular used .ive format has been not extensible from the very beginning. So core developers should always update osgdb_ive itself to add new classes and features. And user-defined nodes and objects can only be stored in a customized file format, or using the .osg plugin supporting a DotOsgWrapper mechanism instead, which is scalable. I decided to mimic this DotOsgWrapper mechanism and try to implement a binary file format (.osg is text format and seems to be hardly to work binarily). And I finally created a preliminary version. Because of the size limitation of our mail list, I have to put the source code tarball on my project site and provide the download link here: http://osgenginebook.googlecode.com/files/osgdb_bin.tar.gz Copy the extracted directory to your osgPlugins location and edit osgPlugins/CMakeLists.txt and add: ADD_SUBDIRECTORY(bin) In the ObjectWrapper header file, I have the ObjectWrapper class mimic osgDB::DotOsgWrapper, and the ObjectRegistry class which work like osgDB::Registry and maintains the wrapper map. The REGISTER_OBJECT_WRAPPER macro is used to declare a new object wrapper, which acts similar with REGISTER_DOTOSGWRAPPER. The InputStream and OutputStream class are use for read/write the OSG scene, which support different read*()/write*() methods. They also both have a shared object-id map, to avoid rereading/rewriting shared nodes and statesets. readObject()/writeObject() is the core function for reading/writing osg native subgraphs. The basic structure of this file format is: | offset |type | contents | 00h | uint | OSG verity value, low | 04h | uint | OSG verity value, high | 08h | uint | Plugin version | 0ch | uint | File attribtues | 10h | uint | Size of author information text | 14h | str | n-sized author information text |14h+n | uint | Size of root node wrapper name |18h+n | str | Root node wrapper name, e.g. "osg::Group" | ... | uint | node id, non-zero value for shared objects | ... | int | Size of written contents, used to vertify data | ... | ... | Attributes of this object and its parent classes. | ... | ... | ... The second step is to write wrappers for every osg core class. An example is: REGISTER_OBJECT_WRAPPER( Geode ) ( new osg::Geode, "osg::Geode", "osg::Object osg::Node osg::Geode", &readGeode, &writeGeode ); Hope you already find that there are few differences between it and the .osg wrappers. You will need to declare the proto, the wrapper's name, its associates (parent wrappers path) and reader/writer functions. Wrappers may be added to meet the extensibility requirements. To update existent wrappers, just append to the read/write functions. It should still be recognized by the old plugin, because of the vertify bits (see the format table). I also developed some initial options for writing with this plugin: - IncludeImageData: Set to save data of osg::Image objects directly. - IncludeImageFile: Set to save image files into this binary file. - UseExternalImage: Set to keep a reference of the image file name only. - WriteImageToFile: Set to write the image data on disk while saving. - AuthorInformation=... : Write author information into the binary file. The core OSG library classes are already finished and included in the wrapper_osg directory, but still not tested enough at present. These are on the TODO list right now, any advices and thoughts will be appreciated: - Decide the extension name: At present I just name it ".bin", short for "binary". A little naive and too common, isn't it? :D - Finish all wrappers of other core libraries, osgAnimation, osgText, osgWidgets and so on. These may be defined inside this plugin or use external dynamic libraries (like the osgwrapper_* files). - Automatically load external wrapper libraries: It would be easy to finish if we merge ObjectRegistry and osgDB::Registry and rewrite the findWrapper() function. - Packing algorithms for vectices and double values, which will be of high performance with geometries and heightfields. - Compression of the entire file, maybe zlib would still be the first choice? - COMPLETELY tests and bug fixes of the plugin, if it is ready to be merged into the osg trunk and be put into use. I'm looking forward to suggestions and testing replies, keeping my fingers crossed. :) Cheers, Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer windows build is broken
Hi Robert, Hi Colin, The current trunk version of "GraphicsWindowWin32" (as of today) cannot be compiled under Windows, since the "HGLRC createContextImplementation()" method declaration is missing in the corresponding header file. After adding it the "osgViewer" library compiles without any problems. Regards, Oleg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deploy OSG application
Dominic Stalder schrieb: > Hi Stephan > > here the answer of my workmate: > > I tried this without luck. After compiling the Frameworks and using them > in my application, I get the following linking errors when building with > Xcode: > > Undefined symbols: > "non-virtual thunk to osgViewer::Viewer::~Viewer()" > "osgDB::readImageFile(std::basic_string, > std::allocator > const&, osgDB::Options const*)" > "osgText::readFontFile(std::basic_string, > std::allocator > const&, osgDB::Options const*)" > "osgViewer::Viewer::checkNeedToDoFrame()" > "non-virtual thunk to osgViewer::Viewer::setStartTick(unsigned long long)" > "non-virtual thunk to osgViewer::Viewer::setSceneData(osg::Node*)" Strange. Check if you are compiling against the same SDK as the frameworks are built with. You can't mix frameworks built for the 10.4 SDK with an app built for 10.5 SDK. What version of osg do you use? I am a bit perplexed, that it doesn't work for you, I am doing this all the time. > Also tried that. Compiled the dylibs with cmake and installed them in > /usr/local/lib. Compiling and linking against them works fine. For > packaging I copied them to the application bundle (to Contents/MacOS/) > and changed all paths using install_name_tool. Starting the application > does not show any linking errors but the following runtime error occurs: Did you mangle all names? You'll have to mangle not only the app, but also the frameworks and the used plugins. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows on two-sided polygons
Hi Wojtek, thanks a lot for your detailed answer. I will work through the example within one of the next holydays, as I am not a professional programmer (I´m a math teacher) and will need some quiet time for a demanding task like this. My software is a math-software to illustrate vector geometry, and thus displays planes and so on simply as polygons. That´s the reason I need two-sided materials (or at least I decided to do so, the alternative would have been to use more massive planes). For the time being it is a comfort for me that I didn´t make a simple mistake and that it is quite some work to adjust the StandardShadowMap to two-sided polygons. Who maintains ShadowMap? I´d like the maintainer to do some tests with my shader. If you think it´s better than the standard one, I´ll refactor it into the Shadow-Map code. For a first impression, see the images in the last mail. Regards & thanks for the example, Andreas Wojciech Lewandowski schrieb: > Hi Andreas, > > If you want to use dual sided materials I believe you will have to > review > and probably modify the shaders in StandardShadowMap.cpp. I am certain > Vertex shader computes ligthing using front lighting and assigns the same > colors to backfacing polygons. > Another issue would be usage of back faces for shadow map rendering. I > guess if you want to use dual face materials you will need to > override this. > So many people have so many varying requests for shadows that my > recomendation for them would be to create their own ShadowTechnique > class based on one of LispSM or MinimalShadowMap or even > StandardShadowMap. But comparing results, this last one does not > really differ that much from ShadowMap which is much easier to override. > When overriding any of above classes its important to override inner > ViewData class which provides View related resources storage and > management. By overriding ViewData::init method you get access to all > statesets used by base classes and you can easily override all state > attributes. > I have prepared an example class (MyViewDependentShadowMap) which > shows how to override any of classes stemming from > ViewDepenedentShadowTechnique. This class illustrate how to add soft > shadows to MinimalDrawBoundsShadowMap class (should be appropriate for > you). Have a look at it and modify to your needs. > > HTH, > Wojtek Lewandowski > > -- > From: "Andreas Goebel" > Sent: Saturday, November 21, 2009 1:57 PM > To: "OpenSceneGraph Users" > Subject: Re: [osg-users] Shadows on two-sided polygons > >> Hi Jean-Sébastien, >> I have turned off those things, and now it works good for me. Should I refactor that in a way that the application programmer can choose the behaviour and submit that? >>> >>> You could, but I think setting those things via overridden state is >>> also acceptable, since if you need that you'll probably know what to >>> set... >>> >> You mean by setting the StateAttribute CullFaces to off and override for >> my shadowed scene? This would probably work (even though it is set with >> override in the ShadowMap? Which will override which?), but not for the >> polygon-offset, as this is not controlled with state. I mean this line: >> >> // negative polygonoffset - move the backface nearer to the eye point so >> that backfaces >>// shadow themselves >>float factor = _polyOffset[0]; >>float units = _polyOffset[1]; >> Another thing: I have written a vertex and a fragment shader that work together in a way that allows the shadows to be rendered exactly in the ambient color. This means that shadowed surfaces look the same as surfaces that face away from the light. This gives a much more natural feeling, and you don´t get false shadows on the backs of polygons. I needed the vertex shader to get the correct ambient color, I think it is not possible to do this with a fragment shader alone. >>> >>> I assume you're talking about osgShadow::ShadowMap? The shaders used >>> for the ViewDependentShadow classes (LightSpacePerspectiveShadowMapDB, >>> CB, VB) already do this. Note that osgShadow::StandardShadowMap is the >>> equivalent of osgShadow::ShadowMap but under the ViewDependentShadow >>> architecture, so you could have used that and you would have gotten >>> the right shadow ambient color. >>> >> It´s great to hear that, I haven´t used the new classes yet, as they are >> not (at least in 2.8.2) part of the shadow-Example and I could not >> easily play with them. However, I have made an option in my program to >> use the StandardShadowMap, and it does not work for me (yet). Here are >> the problems: >> >> - the side facing away from a light is not dark, example: >> http://raumgeometrie.de/NeueBilder/testbilder/IncorrectBack.png >> >> - the backside of a shadowed plane shows the shadow, too: >> >> http://raumgeometrie.de/NeueBilder/testbilder/IncorrectShadowOnBack.png >>
