Re: [osg-users] MultiThreaded problem in latest SVN
I'm sure you already knew this, but just in case not... :)
svn diff \
--old http://www.openscenegraph.com/svn/osg/OpenSceneGraph/[EMAIL PROTECTED] \
--new http://www.openscenegraph.com/svn/osg/OpenSceneGraph/[EMAIL PROTECTED]
...will give you the diff, which I've also attached. SVN rocks. :)
On Fri, 2007-07-13 at 21:46 +0100, Robert Osfield wrote:
Hi Adrian,
I did some testing this evening and found that when running in the
CullThreadPerCameraDrawThreadPerContext thread model I get a hang on
start up. All the rest of the threading models works fine,
CullThreadPerCameraDrawThreadPerContext even works fine when I run on
a single head.
I have isolated this particular problem to being in revision 7118 and
later, 7117 works fine in all threading models, at least on my
machine. I don't know if this issue is related to the one you've seen
but perhaps it might be and you'll at least know which revision to go
back to.
The changes I made since 7117 aren't major changes, I don't know yet
exactly what went wrong, but at least I know roughly where to look.
I'll do this over the weekend.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Index: include/osgUtil/GLObjectsVisitor
===
--- include/osgUtil/GLObjectsVisitor (revision 7117)
+++ include/osgUtil/GLObjectsVisitor (revision 7118)
@@ -113,6 +113,20 @@
};
+class GLObjectsOperation : public osg::GraphicsOperation
+{
+public:
+
+GLObjectsOperation(osg::Node* subgraph, GLObjectsVisitor::Mode mode = GLObjectsVisitor::COMPILE_DISPLAY_LISTS|GLObjectsVisitor::COMPILE_STATE_ATTRIBUTES|GLObjectsVisitor::CHECK_BLACK_LISTED_MODES);
+
+virtual void operator () (osg::GraphicsContext* context);
+
+protected:
+
+osg::ref_ptrosg::Node _subgraph;
+GLObjectsVisitor::Mode _mode;
+};
+
}
#endif
Index: include/osg/OperationThread
===
--- include/osg/OperationThread (revision 7117)
+++ include/osg/OperationThread (revision 7118)
@@ -130,7 +130,7 @@
OperationThreads_operationThreads;
};
-/** GraphicsThread is a helper class for running OpenGL GraphicsOperation within a single thread assigned to a specific GraphicsContext.*/
+/** OperationThread is a helper class for running Operation within a single thread.*/
class OSG_EXPORT OperationThread : public Referenced, public OpenThreads::Thread
{
public:
Index: include/osg/GraphicsThread
===
--- include/osg/GraphicsThread (revision 7117)
+++ include/osg/GraphicsThread (revision 7118)
@@ -18,6 +18,9 @@
namespace osg {
+class GraphicsContext;
+
+/** GraphicsThread is a helper class for running OpenGL GraphicsOperation within a single thread assigned to a specific GraphicsContext.*/
class OSG_EXPORT GraphicsThread : public osg::OperationThread
{
public:
@@ -28,17 +31,30 @@
virtual void run();
};
+struct OSG_EXPORT GraphicsOperation : public Operation
+{
+GraphicsOperation(const std::string name, bool keep):
+Operation(name,keep) {}
+
+/** Override the standard Operation opertator and dynamic cast object to a GraphicsContext,
+ * on success call operation()(GraphicsContext*).*/
+virtual void operator () (Object* object);
+
+virtual void operator () (GraphicsContext* context) = 0;
+};
+
+
/** SwapBufferOperation calls swap buffers on the GraphicsContext.*/
-struct OSG_EXPORT SwapBuffersOperation : public Operation
+struct OSG_EXPORT SwapBuffersOperation : public GraphicsOperation
{
SwapBuffersOperation():
-Operation(SwapBuffers,true) {}
+GraphicsOperation(SwapBuffers,true) {}
-virtual void operator () (Object* context);
+virtual void operator () (GraphicsContext* context);
};
/** BarrierOperation allows one to syncronize multiple GraphicsThreads with each other.*/
-struct OSG_EXPORT BarrierOperation : public Operation, public OpenThreads::Barrier
+struct OSG_EXPORT BarrierOperation : public GraphicsOperation, public OpenThreads::Barrier
{
enum PreBlockOp
{
@@ -48,36 +64,36 @@
};
BarrierOperation(int numThreads, PreBlockOp op=NO_OPERATION):
-Operation(Barrier, true),
+GraphicsOperation(Barrier, true),
OpenThreads::Barrier(numThreads),
_preBlockOp(op) {}
virtual void release();
-virtual void operator () (Object* context);
+virtual void operator () (GraphicsContext* context);
PreBlockOp _preBlockOp;
};
/** ReleaseContext_Block_MakeCurrentOperation releases the context for another thread to aquire,
* then blocks waiting for context to be released, once the block is release the context is re-aqquired.*/
-struct OSG_EXPORT
[osg-users] osgHUD (Week 2 1/2)
It's week 3 of my working on osgHUD in my free time (although it's only been 2 weeks really since I took a small break to beat Gears Of Wars, awesome game...), but I wanted to show another quick video of some of the progress, since I've actually gotten a lot of positive encouragement and e-mails. This demonstrates a group of fully scalable, rotatable, moveable, and resizable Decorated Window objects inside of osgviewer. Three important things to notice are: 1. The Decorated Window class is different than a simple Window class in that is has a texture border region that can be resized. In osgHUD, Window objects are just simple rectangles that can only be scaled, moved, and rotated--the Window class itself provides no methods of changing it's internal geometry, only transforming them via a MatrixTransform. The DecorateWindow object inherits from Window and will provide many of the behaviors people have to expect from a typical Window, i.e: resizing, closing, minimizing, etc. 2. The Decorated Window object rotates around the orthographic 0,0,0 coordinate. I've tried a lot of different approaches to rotating a DecoratedWindow around it's own middle point, but most of them fail the second you can change the internal geometry by resizing it larger or small. To do this properly I'll have to employ some extra logic, and at the moment I've decided to leave the behavior as-is (I spent a few days experimenting with different techniques that didn't work; perhaps later I can write a more thorough post that discusses my failed approaches and get one of you OSG/OpenGL gurus to tell me what I was doing wrong. :)) 3. The fragment shader I'm using on the DecoratedWindow background doesn't look nearly as cool in this video as it does otherwise. Ohwell. :) The video was made on Linux (of course) and ffmpeg'd into WMV for those of you using Windows. http://cherustone.com/osgHUD5.wmv ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgHUD (Week 2 1/2)
Oh! Yeah! Here's one of the WindowManager object (a derivative of osg::Switch that manages all of the windows assigned to it) being added to a typical 3D perspective camera rather than a 2D orthographic camera. You'll notice a number of weird things (some sorting/depth issues and texture anomalies), but it's mostly to demonstrate the mechanics behind manipulating the windows and how this isn't bound to a 2D environment necessarily... http://cherustone.com/osgHUD6.wmv On Thu, 2007-07-12 at 11:22 -0400, Jeremy L. Moles wrote: It's week 3 of my working on osgHUD in my free time (although it's only been 2 weeks really since I took a small break to beat Gears Of Wars, awesome game...), but I wanted to show another quick video of some of the progress, since I've actually gotten a lot of positive encouragement and e-mails. This demonstrates a group of fully scalable, rotatable, moveable, and resizable Decorated Window objects inside of osgviewer. Three important things to notice are: 1. The Decorated Window class is different than a simple Window class in that is has a texture border region that can be resized. In osgHUD, Window objects are just simple rectangles that can only be scaled, moved, and rotated--the Window class itself provides no methods of changing it's internal geometry, only transforming them via a MatrixTransform. The DecorateWindow object inherits from Window and will provide many of the behaviors people have to expect from a typical Window, i.e: resizing, closing, minimizing, etc. 2. The Decorated Window object rotates around the orthographic 0,0,0 coordinate. I've tried a lot of different approaches to rotating a DecoratedWindow around it's own middle point, but most of them fail the second you can change the internal geometry by resizing it larger or small. To do this properly I'll have to employ some extra logic, and at the moment I've decided to leave the behavior as-is (I spent a few days experimenting with different techniques that didn't work; perhaps later I can write a more thorough post that discusses my failed approaches and get one of you OSG/OpenGL gurus to tell me what I was doing wrong. :)) 3. The fragment shader I'm using on the DecoratedWindow background doesn't look nearly as cool in this video as it does otherwise. Ohwell. :) The video was made on Linux (of course) and ffmpeg'd into WMV for those of you using Windows. http://cherustone.com/osgHUD5.wmv ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Build a new machine, comments?
On Thu, 2007-07-12 at 19:36 +0100, Robert Osfield wrote: I guess the next question once I start building it is... what Linux distribution to go for. I'm not sticking with Suse as I had done for the past 6 years. Must admit I'm very tempted by a debian based distribution as the I just believe in the approach package management, it just seems the right way to tackle things in the 21st century. Another requirement is that I much prefer KDE over Gnome. Although I personally use Fedora because it just looks better than everything else out there (in terms of visual appeal, something that probably means more to us UI freaks than hardcore developers), if you want KDE and apt you can't go wrong with Kubuntu. We have lots of customers who have reported little-to-no problems with it... Oh its also got to have good support from NVidia's OpenGL drivers. Thoughts? Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] BUTTONS IN THE SCENE
I should add here that if you're interested and willing to work w/ less-than-alpha code, osgHUD can already do what you want... On Mon, 2007-07-09 at 16:14 -0400, Jeremy L. Moles wrote: On Mon, 2007-07-09 at 16:24 +0200, Gianluca Balducci wrote: Hi to everybody, it's still me here. I'm getting some problems trying to figure out how to put buttons in the scene; i mean i designed some simple geometries on top of the scene, i should somehow activate them so that when i click on them with the mouse the action i set will happen... any idea??? My own personal project, osgHUD, aims to squash this problem in a native OSG way once and for all. However, there are many months yet to go, so perhaps something like OSGUIsh is best for the interim. It certainly makes a lot of things I had trouble doing cleanly (focusing, for example) easier. :) I would say my current level of completion is about 20%; I'm currently working on a layout management scheme... thanks gianlup _ Hai sempre tutte le risposte? Sfida gli amici su Messenger con Duel Live! http://specials.it.msn.com/DuelLive.aspx ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] BUTTONS IN THE SCENE
On Tue, 2007-07-10 at 20:37 +0100, Himar Carmona wrote: Hi, osgHUD looks interesting. I'm curious about it. What features are you thinking about to incorporate? Will it be a general purpose GUI or will it be oriented to an specific area (like games and so on)? It's just curiosity. Well, whether it will be useful to other people or not (or if I even have the skill to make good, reusable software) remains to be seen. :) However, under the assumption that I DO, I intend osgHUD to be a game-centric UI kit; that is to say, I have no intention of implementing a suite of widgets such as you would find in Qt or GTK or similar. Instead, I want to create a simple framework for sensibly managing (moving, scaling, rotating, clicking, dragging, resizing, etc.) rectangular regions of a 2D display and provide an easy way to populate and update this region using standard osg Image data. This seems to be closest to be in sync with Robert's design of OSG thus far, and ahdering to that is my best chance of getting people to take it seriously. :) Thanks ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] BUTTONS IN THE SCENE
On Tue, 2007-07-10 at 22:01 +0100, Himar Carmona wrote: Thanks for the response. As you have seen, there is a real interesting in the community to have some toolkit for developing GUI in OSG. Just an idea: What if you also consider doing it on 3D? Something like a planar object that you can make sensible to mouse and keyboard events. Well, just an idea. :) To be honest, it already kinda' works this way. :) Basically, you add a WindowManager object to your scene, and it does the housekeeping. If the WindowManager is added to a Camera set in 2D Orthographic mode, everything works as intended. If it's added directly to the viewer it still works (kinda), though the code makes some assumptions about view and produces weird behavior. I'll try and make a video of this tomorrow, it does end up being relatively neat. :) (i.e., an interface widget painted on a spinning cube, etc.) Keep moving... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] BUTTONS IN THE SCENE
On Mon, 2007-07-09 at 16:24 +0200, Gianluca Balducci wrote: Hi to everybody, it's still me here. I'm getting some problems trying to figure out how to put buttons in the scene; i mean i designed some simple geometries on top of the scene, i should somehow activate them so that when i click on them with the mouse the action i set will happen... any idea??? My own personal project, osgHUD, aims to squash this problem in a native OSG way once and for all. However, there are many months yet to go, so perhaps something like OSGUIsh is best for the interim. It certainly makes a lot of things I had trouble doing cleanly (focusing, for example) easier. :) I would say my current level of completion is about 20%; I'm currently working on a layout management scheme... thanks gianlup _ Hai sempre tutte le risposte? Sfida gli amici su Messenger con Duel Live! http://specials.it.msn.com/DuelLive.aspx ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] CEGUI
On Tue, 2007-07-03 at 12:43 +0200, Emmanuel Roche wrote: By the way, sure CEGUI is not recommendable but is there another good possibility you would recommend to build GUIs in OSG ? I'm working on one myself. :) Just need time... time... who ever has enough? At any rate, if you don't use CEGUI there really isn't much else. Hopefully I can have the osgHUD NodeKit working in the coming months. Manu. 2007/7/3, Robert Osfield [EMAIL PROTECTED]: Hi Guy, The osgcegui example was my abortive attempt at getting CEGUI to work in a well that integrates well with the OSG. I say abortive because CEGUI really is a bit brain dead when it comes to managing multiple graphics contexts and multi-threading, its can't do it at all and doesn't look like it'll ever do it without a major rewrite. Some OSG users have got CEGUI to work with the OSG, and there are some suggestions in the osg-users archives about this. Personally I was unimpressed with CEGUI, its just not well designed or implemented library, its makes too many assumptions and restrictions on its usage to make it particularly useful beyond single window, single threaded games. I certainly wouldn't recommend it. Robert. On 7/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I tried to run the osgcegui example, and no GUI was rendered. All the GUI creation code was taken from CEGUI example (which works). I didn't get any errors from CEGUI or OSG. I also tried to set the renderGUI function as post callback of the camera with no better results. any ideas? is it something with the Zbuffer? or Z position of the GUI? thanks, Guy. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] ViewerEventHandlers problem with custom GUIEventHandlers
On Mon, 2007-07-02 at 20:55 +0300, Panagiotis Papadakos wrote: Hello everybody! I have an OSGKeyboardEventHandler : public osgGA::GUIEventHandler keyboard handler, whose handle method returns true when for example 's' is pressed. My problem is that because I have also added the osgViewer::StatsHandler to my viewer i also see the stats printed on my screen! Am I doing something wrong? Thank you. I would guess that one does key press (perhaps yours), and the other release (perhaps StatsHandler). I haven't checked the source to confirm, but I bet this is what is happening... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] ViewerEventHandlers problem with custom GUIEventHandlers
On Mon, 2007-07-02 at 21:32 +0300, Panagiotis Papadakos wrote: Hi Jeremy and thanks for your quick response. I think you have a point there. But even if I inverse my handler, things again do not work. I also tried setting setHandled to true but again nothing! I looked at the code and StatsHandler works on KEYDOWN; so, just make sure your event handler is front of the StatsHandler when you add it to the viewer (either by hand or by calling push_front()) and return true on that event and you should be okay. Alternatively, you can call: statsHandler-setKeyEventTogglesOnScreenStats() ...to change it from S to something else. On Monday 02 July 2007 21:04, Jeremy L. Moles wrote: On Mon, 2007-07-02 at 20:55 +0300, Panagiotis Papadakos wrote: Hello everybody! I have an OSGKeyboardEventHandler : public osgGA::GUIEventHandler keyboard handler, whose handle method returns true when for example 's' is pressed. My problem is that because I have also added the osgViewer::StatsHandler to my viewer i also see the stats printed on my screen! Am I doing something wrong? Thank you. I would guess that one does key press (perhaps yours), and the other release (perhaps StatsHandler). I haven't checked the source to confirm, but I bet this is what is happening... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osg 2.0.0 vs71sp1 win32 installer available
On Tue, 2007-06-19 at 08:41 -0500, Mike Weiblen wrote: Hi all, An installer executable and zip archive of win32 OSG 2.0.0 binaries built with VisualStudio 7.1 SP1 are being uploaded at this moment to http://mew.cx/pub/ (a temporary URL until I update the webpage) An installer of binaries generated with VisualStudio 8.0 SP1 is in progress. Feedback/testing of the 7.1 version before the 8.0 version is complete would be welcome. FYI the 3rdParty dependencies used for this build have been updated to the latest zlib and libpng to address security issues. The exact set of 3rdParty libraries used are available at https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/tags/3rd_party_for_osg_2_0_0_vs71 For the curious, the verbatim build environment used to create this installer is available at https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/osgbuilds/tags/build_for_osg_2_0_0_vs71_build_1 cheers -- mew Thanks a lot for this! I know jack about Windows development, but these at least give me some way of getting an idea of how performance in OSG is in Windows. :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Generating Interest :)
Over the last week or so I've really been experimenting with learning various and necessary components of OSG (I posted about this last week) required to put together a HUD/UI toolkit uses 100% native OSG without any reproduction of math/2D/3D classes or glueware in an external library. This morning I created a video of it's very first steps towards awesomeness to hopefully generate a small bit of interest in my endeavor and perhaps get some opinions. Any expert advice or things to avoid from people who have done something similar in the past would be great. The current name idea is osgHUD; is this already taken? The video link is here (made in Linux using Yukon): http://cherustone.com/osgHUD.avi Some things demonstrated (please, forgive me if I used the wrong terminology; hopefully the ideas are understandable): - The window borders are drawn using Cairo (so that they're nice and round and antialiased). They can be scaled to any size without loss in clarity (but suffer from the fact when drawn, they don't perfectly blend to the most discerning eye because they're actually rendered on a full transparent surface and not on top of the actual OpenGL scene/color buffer). - The windows are post-processed by a GLSL fragment shader (just for fun!) that both creates the progressive scanlines and colors the windows darker or lighter depending on their Y position. - The windows are moved and rotated; resizing works, but I changed the architecture a bit last night, and trying to do resize ATM segfaults. :) I'll fix this up and maybe show another video next week with that working and other window decorations (minimize and close buttons, etc.) The general idea is this: in my opinion, web developers (or I should clarify and say Flash developers) have really been kicking the butts of game designers for a long time with regards to elegant, clean, and effective interface design. Part of this is because of the vector graphics backend of Flash (which osgHUD will harness by using Cairo) and part of this is because 2D graphics usually knows how to properly blend with the surface below them (something OpenGL can't do easily without a hit in performance). I feel like I can achieve the happen medium of crispness vs. performance; think Flash quality UI's for OpenGL/OSG. At the very least it should give OSG developers some way to quickly throw together a few UI widgets and dialogs for prototyping, even if they end up using something custom in the end. I should mention that, in doing all this, my primary development constraints are: - Every UI thing (windows, buttons, etc.) should be 100% scalable, translate, and rotatable with any loss in clarity; what looks good at 1920x1200 should also look good at 800x600. - To accommodate custom widgets, the system will be developed in a general sense where the user defines a layout of rectangular regions which receive all the standard events a modern toolkit provides: mouseEnter, mouseOver, leftClicked, focused, etc. A small set of prebuilt interface elements will be provided (resizable windows, buttons, progress meter, etc.) but for the most part it will be assumed the user wants to create interface components that integrate naturally with their project. - As much as is reasonably possible will done using programmable functionality; fixed fallbacks might be considered, but it's very unlikely. I know this might turn off some users, but I don't think it's asking too much to require programmable functionality in 2007. Besides, if the idea is to push the envelope but stay fast, I don't see a way of getting around it. :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Generating Interest :)
On Tue, 2007-06-19 at 17:13 +0200, Stephan Maximilian Huber wrote: Hi Jeremy, the video looks very nice. I am also investigating cairo and osg ( I need to import SVG files for a new application) and it works ok. Jeremy L. Moles schrieb: - The window borders are drawn using Cairo (so that they're nice and round and antialiased). They can be scaled to any size without loss in clarity (but suffer from the fact when drawn, they don't perfectly blend to the most discerning eye because they're actually rendered on a full transparent surface and not on top of the actual OpenGL scene/color buffer). If I understand you correctly, then you can fix this very simple: Cairo uses premultiplied alpha, if you change your blendfunc, your alpha should be ok again. geode-getOrCreateStateSet()-setAttributeAndModes(new osg::BlendFunc(osg::BlendFunc::ONE, osg::BlendFunc::ONE_MINUS_SRC_ALPHA)); Wow, that made a huge difference. :) I'm tempted to make another video just to show the amazing difference in quality... Out of curiosity, is your code public? I'm curious to see how someone else integrated Cairo and OSG. You can find my implementation (osgCairo) here: svn co http://svn.const.lugatgt.org/osgCairo/trunk Are you somehow directly using the main OpenGL color buffer as your surface (is this even possible?) Are you drawing on individual textures (also Cairo surfaces) similar to me? Perhaps I can steal all your good ideas and we could call it collaboration!? :) *grin* here's my demo-screenshot ;-) cheers, Stephan ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Generating Interest :)
On Tue, 2007-06-19 at 11:31 -0400, Jeremy L. Moles wrote: On Tue, 2007-06-19 at 17:13 +0200, Stephan Maximilian Huber wrote: Hi Jeremy, the video looks very nice. I am also investigating cairo and osg ( I need to import SVG files for a new application) and it works ok. Jeremy L. Moles schrieb: - The window borders are drawn using Cairo (so that they're nice and round and antialiased). They can be scaled to any size without loss in clarity (but suffer from the fact when drawn, they don't perfectly blend to the most discerning eye because they're actually rendered on a full transparent surface and not on top of the actual OpenGL scene/color buffer). If I understand you correctly, then you can fix this very simple: Cairo uses premultiplied alpha, if you change your blendfunc, your alpha should be ok again. geode-getOrCreateStateSet()-setAttributeAndModes(new osg::BlendFunc(osg::BlendFunc::ONE, osg::BlendFunc::ONE_MINUS_SRC_ALPHA)); Wow, that made a huge difference. :) I'm tempted to make another video just to show the amazing difference in quality... Okay, yeah, couldn't resist: Original (bland): http://cherustone.com/osgHUD.avi New (bright!): http://cherustone.com/osgHUD2.avi Out of curiosity, is your code public? I'm curious to see how someone else integrated Cairo and OSG. You can find my implementation (osgCairo) here: svn co http://svn.const.lugatgt.org/osgCairo/trunk Are you somehow directly using the main OpenGL color buffer as your surface (is this even possible?) Are you drawing on individual textures (also Cairo surfaces) similar to me? Perhaps I can steal all your good ideas and we could call it collaboration!? :) *grin* here's my demo-screenshot ;-) cheers, Stephan ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Generating Interest :)
On Tue, 2007-06-19 at 11:28 -0500, Decarlo, Thomas R. (LARC-B702)[NCI INFORMATION SYSTEMS] wrote: Jeremy, What codec are you using for these videos? I cannot play them on either Windoze (WMP, RealPlayer, or QuickTime) or Linux (RealPlayer) MPEG4 (via ffmpeg) inside of the AVI container format; no audio. :) -- Thom DeCarlo - Never Underestimate the Power of Stupid People in Large Vehicles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy L. Moles Sent: Tuesday, June 19, 2007 11:35 AM To: osg users Subject: Re: [osg-users] Generating Interest :) On Tue, 2007-06-19 at 11:31 -0400, Jeremy L. Moles wrote: On Tue, 2007-06-19 at 17:13 +0200, Stephan Maximilian Huber wrote: Hi Jeremy, the video looks very nice. I am also investigating cairo and osg ( I need to import SVG files for a new application) and it works ok. Jeremy L. Moles schrieb: - The window borders are drawn using Cairo (so that they're nice and round and antialiased). They can be scaled to any size without loss in clarity (but suffer from the fact when drawn, they don't perfectly blend to the most discerning eye because they're actually rendered on a full transparent surface and not on top of the actual OpenGL scene/color buffer). If I understand you correctly, then you can fix this very simple: Cairo uses premultiplied alpha, if you change your blendfunc, your alpha should be ok again. geode-getOrCreateStateSet()-setAttributeAndModes(new osg::BlendFunc(osg::BlendFunc::ONE, osg::BlendFunc::ONE_MINUS_SRC_ALPHA)); Wow, that made a huge difference. :) I'm tempted to make another video just to show the amazing difference in quality... Okay, yeah, couldn't resist: Original (bland): http://cherustone.com/osgHUD.avi New (bright!): http://cherustone.com/osgHUD2.avi Out of curiosity, is your code public? I'm curious to see how someone else integrated Cairo and OSG. You can find my implementation (osgCairo) here: svn co http://svn.const.lugatgt.org/osgCairo/trunk Are you somehow directly using the main OpenGL color buffer as your surface (is this even possible?) Are you drawing on individual textures (also Cairo surfaces) similar to me? Perhaps I can steal all your good ideas and we could call it collaboration!? :) *grin* here's my demo-screenshot ;-) cheers, Stephan ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgshadow objects are black now
On Fri, 2007-06-15 at 15:54 +0200, Mario Valle wrote: ./osgshadow show entirely black objects now. Same thing is happening to me on Linux, checkout as of a few minutes ago... Linux 32, GeForce 6800 GS driver version: 8762 checkout today h15:36 Sorry for mixing threads. mario ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] GLSL Orthographic Projection
On Thu, 2007-06-14 at 15:59 +0100, Robert Osfield wrote:
HI Jeremy,
GLSL programs are of the form:
void main()
{
...
}
Rather than have a int return type as you've done.
This may or may not be causing the problem though, but worth a try.
Also look for any OpenGL errors being reported.
Oops, the int was just a typo on my part in the e-mail; the code is
actually void. Can I assume though by your response that it should
work, and that the error is probably somewhere in my code and not that I
need to pass in some projection matrix not available to GLSL by default?
Robert.
On 6/14/07, Jeremy L. Moles [EMAIL PROTECTED] wrote:
I've been writing a fragment shader for the last few days to do a number
of interesting alpha blending things for my UI NodeKit that I've been
working on. So far, with only using a fragment shader (and allowing
OpenGL to handle the vertex functionality) everything has worked
astoundingly. ;) I'm using a standard Camera-in-Camera setup, where my
HUD is another Camera attached to the Viewers internal camera.
This morning I tried to add the most simple vertex shader with no
success:
int main() {
gl_Position = ftransform();
}
...but it results in my not actually seeing anything. I'm sure it has
something to do with how I have the Camera setup inside of another, but
I'm not really sure how to proceed.
Has anyone done something like this before using OSG? Any advice on
getting the position calculated in a vertex shader the same way OSG does
it by default when using the HUD Camera-in-Camera setup?
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] RecordCameraPathHandler Before 2.0 (For QuickStartGuide)
I had a whack at finishing the last little bit of the
RecordCameraPathHandler thing we talked about some earlier this month.
Here I quote Robert from a previous response:
I haven't added in the 'Z' functionality suggested by Paul yet though,
this is a little more complicated because osgViewer::Viewer isn't hard
wired to use a KeySwitchMatrixManipulator like osgProducer::Viewer
was. What will need to be done is for a check against the
Viewer::getCameraManipulator() to see if it is a
KeySwitchMatrixManipulator, if not then insert one, and add this
original manipulator plus an AnimationPathManipulator, then switching
this to current selected one.
Well, I gave that a shot and the code ended up being horribly buggy and
dirty. I implemented something simpler that I think should do for now
so that the information in the QuickStartGuide is accurate when it's
published. :)
Attached is a diff (for the curious to view inline) and the two full
modified files up-to-date as of SVN this morning.
P.S. I copied this to osg-users so Paul Martz would be sure and see it
and make sure the attempt is concurrent with the information in the QSG.
Index: include/osgViewer/ViewerEventHandlers
===
--- include/osgViewer/ViewerEventHandlers (revision 6958)
+++ include/osgViewer/ViewerEventHandlers (working copy)
@@ -17,6 +17,7 @@
#include osg/AnimationPath
#include osgText/Text
#include osgGA/GUIEventHandler
+#include osgGA/AnimationPathManipulator
#include osgViewer/GraphicsWindow
#include osgViewer/Viewer
@@ -218,17 +219,14 @@
Event handler allowing the user to record the animation path of a camera. In it's current
implementation, this handler cannot guarantee the final view matrix is correct; it is
conceivable that the matrix may be one frame off. Eh--not a big deal! :)
-TODO: Find the good filename.
-TODO: Write as we go, not when it's all done.
-TODO: Create osgviewer on-screen indication that animation is taking place.
-TODO: Explore multi-cameras thing.
-TODO: Investigate crash if non-focused camera?
+TODO: Write the file as we go, not when it's all done.
+TODO: Create an osgviewer on-screen indication that animation is taking place.
*/
class OSGVIEWER_EXPORT RecordCameraPathHandler : public osgGA::GUIEventHandler
{
public:
-RecordCameraPathHandler();
+RecordCameraPathHandler(const std::string filename = saved_animation.path);
virtual void getUsage(osg::ApplicationUsage usage) const;
@@ -236,12 +234,16 @@
protected:
-bool _currentlyRecording;
-double _interval;
-double _delta;
-osg::Timer_t _animStartTime;
-osg::Timer_t _lastFrameTime;
-osg::ref_ptrosg::AnimationPath _animPath;
+std::string _filename;
+bool _currentlyRecording;
+bool _currentlyPlaying;
+double_interval;
+double_delta;
+osg::Timer_t _animStartTime;
+osg::Timer_t _lastFrameTime;
+osg::ref_ptrosg::AnimationPath _animPath;
+osg::ref_ptrosgGA::AnimationPathManipulator _animPathManipulator;
+osg::ref_ptrosgGA::MatrixManipulator_oldManipulator;
};
}
Index: src/osgViewer/ViewerEventHandlers.cpp
===
--- src/osgViewer/ViewerEventHandlers.cpp (revision 6958)
+++ src/osgViewer/ViewerEventHandlers.cpp (working copy)
@@ -343,17 +343,19 @@
return false;
}
-RecordCameraPathHandler::RecordCameraPathHandler():
+RecordCameraPathHandler::RecordCameraPathHandler(const std::string filename):
+_filename(filename),
_currentlyRecording(false),
+_currentlyPlaying(false),
_delta(0.0f),
_lastFrameTime(osg::Timer::instance()-tick()),
_animStartTime(0)
{
_animPath = new osg::AnimationPath();
-const char* str = getenv(OSG_CAMERA_ANIMATION_FPS);
+const char* str = getenv(OSG_RECORD_CAMERA_PATH_FPS);
-if(str) _interval = 1.0f / atof(str);
+if (str) _interval = 1.0f / atof(str);
else _interval = 1.0f / 25.0f;
}
@@ -361,6 +363,7 @@
void RecordCameraPathHandler::getUsage(osg::ApplicationUsage usage) const
{
usage.addKeyboardMouseBinding(z, Toggle camera path recording.);
+usage.addKeyboardMouseBinding(Z, Load local camera path recording.);
}
bool RecordCameraPathHandler::handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter aa)
@@ -376,6 +379,7 @@
{
case(osgGA::GUIEventAdapter::KEYUP):
{
+// The user has requested to toggle recording.
if
Re: [osg-users] ANN: OSG Quick Start Guide final revision now available
On Thu, 2007-06-14 at 14:58 -0600, Paul Martz wrote: Hi folks -- I've made some final tweaks to the OpenSceneGraph Quick Start Guide. The latest information on it (and the new OSG Reference Manual v1.2) is available at: http://www.osgbooks.com In addition to several fixes and clarifications, the two most notable enhancements to the QSG are the addition of an Index and the availability of a lower-cost BW edition. If you've been putting off buying a print copy until the final revision, wait no longer. A portion of sales revenue will be used to fund further developments for this and other OSG documentation. Please consider buying a print copy to assist in the documentation effort. Copy is on the way. :) I'll take time to write an honest review when I get it... it's a small price to pay, really, if it means more effort may be directed in the future to documentation. Maybe that way I won't pollute the lists with my dumb questions... I'd also like to solicit the community's help in getting the word out. Are there other Web sites that could display information about this book's availability? Would someone be willing to write a short review and post it to Lulu.com? Other ideas for publicizing the OSG books are appreciated. (Just some stats, FYI: Since creating the QSG, there have been over 4000 hits to its Web page at Lulu.com; over 900 downloads of the PDF, and so far 7 print copies have been sold, which will be rarities in the future as they are all first editions. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG Quick Start Guide -- update on status
On Wed, 2007-06-13 at 10:39 -0600, Paul Martz wrote: Hi all -- I know many of you have been waiting for the revision to the OSG Quick Start Guide, so I wanted to give you an update. I posted a new version to Lulu on June 7. However, there were a couple omissions and errors. As a result, I expect to have a revised revision available sometime late tomorrow. The new version contains many improvements over the April 7 version, most all changes based on technical review feedback (thanks to all who provided comments). As before, the QSG will be available in a color printing and as a free PDF download. However, the new version is also available in a BW printing to make it more affordable. When I get these final changes uploaded tomorrow, I'll post here. I apologize for the delay. Sweet... I just submittted the Shift-Z thing for the RecordCameraPathHandler; I figured I'd respond here too, since your e-mail thinks I'm spamming 'ya. :) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Saving children of a node as separate .osg files
On Wed, 2007-06-13 at 20:59 +0100, Robert Osfield wrote: Hi Catherine, The osgDB::writeNodeFile(Node*, std::string) method can work on any node in the scene graph so to write out a child: osgDB::write(parent-getChild(childNum), mychildfile.osg); This might be a fun kind of NodeVisitor to write... something that traversed the scene and built a directory structure based on graph's hierarchy and wrote each encountered drawable to a file, along with it's parental information back up the last known drawable. Just thinking out loud, though... On 6/13/07, Catherine Peloquin [EMAIL PROTECTED] wrote: Hello all, I have just started working with OpenSceneGraph, so I apologize if this question is simple. I am working on an OSG/GTK project that imports stock.osg files into a viewer where they can be manipulated. The imported objects are arranged in a tree structure beneath a main node node. I need to save each of the imported and manipulated objects in the scenegraph into separate .osg files. My original idea was to get the main node, find out how many children (imported objects) it had, and iterate for each child to getChild() and then somehow saving that child. The problems I encountered were that I could not figure out how to choose the main node without having the user select it, and then found that getNumChildren() and getChild() were group, not node functions. I also am not sure what the function is to save a child as a .osg file. Does anyone have any ideas as to how I could save the children separately? Just to note, I am working on a Windows XP machine. Thank you, Catherine Peloquin ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Saving children of a node as separate .osg files
On Wed, 2007-06-13 at 15:22 -0500, Catherine Peloquin wrote: Thanks. This might be a fun kind of NodeVisitor to write... I'll find out soon enough. ;) :) Well, I'm still a bit of an OSG newb myself, but it might easier to work backward, as it were, since--if your SceneGraphs look like mine--you won't want to write a Transform without also include the thing it transforms. If you get it working, I'd be really interested in seeing it. :) Catherine On 6/13/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: On Wed, 2007-06-13 at 20:59 +0100, Robert Osfield wrote: Hi Catherine, The osgDB::writeNodeFile(Node*, std::string) method can work on any node in the scene graph so to write out a child: osgDB::write(parent-getChild(childNum), mychildfile.osg); This might be a fun kind of NodeVisitor to write... something that traversed the scene and built a directory structure based on graph's hierarchy and wrote each encountered drawable to a file, along with it's parental information back up the last known drawable. Just thinking out loud, though... On 6/13/07, Catherine Peloquin [EMAIL PROTECTED] wrote: Hello all, I have just started working with OpenSceneGraph, so I apologize if this question is simple. I am working on an OSG/GTK project that imports stock.osg files into a viewer where they can be manipulated. The imported objects are arranged in a tree structure beneath a main node node. I need to save each of the imported and manipulated objects in the scenegraph into separate .osg files. My original idea was to get the main node, find out how many children (imported objects) it had, and iterate for each child to getChild() and then somehow saving that child. The problems I encountered were that I could not figure out how to choose the main node without having the user select it, and then found that getNumChildren() and getChild() were group, not node functions. I also am not sure what the function is to save a child as a .osg file. Does anyone have any ideas as to how I could save the children separately? Just to note, I am working on a Windows XP machine. Thank you, Catherine Peloquin ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] New OSG logo
On Wed, 2007-06-13 at 22:33 +0100, martin.lavery wrote: Hi guys, With the soon approaching version of OpenSceneGraph 2.0, we have put together a possible replacement for the OpenSceneGraph logo. You can see it through the link below: http://www.openscenegraph.com/osgwiki/pmwiki.php/Screenshots/Logo We would love here your opinion on logo, constructive criticism is very much welcome. :-) Awesome. :) Do you have the source SVG for it? That would be enormously cool to play with in the OSG+Cairo work I'm doing... at any rate, it is very crisp, clean, and modern. I give two thumbs up. Kind Regards, Martin ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] New OSG logo
On Wed, 2007-06-13 at 22:56 +0100, martin.lavery wrote: Hi Jeremy, I have uploaded a svg version up on to the same page. :-) Many thanks. :) I'm always glad to see graphics folks (who often wildly differ from design folks) appreciate the wholesome goodness of vector graphics and provide assets as such. Kind Regards, Martin On 13 Jun 2007, at 22:47, Jeremy L. Moles wrote: On Wed, 2007-06-13 at 22:33 +0100, martin.lavery wrote: Hi guys, With the soon approaching version of OpenSceneGraph 2.0, we have put together a possible replacement for the OpenSceneGraph logo. You can see it through the link below: http://www.openscenegraph.com/osgwiki/pmwiki.php/Screenshots/Logo We would love here your opinion on logo, constructive criticism is very much welcome. :-) Awesome. :) Do you have the source SVG for it? That would be enormously cool to play with in the OSG+Cairo work I'm doing... at any rate, it is very crisp, clean, and modern. I give two thumbs up. Kind Regards, Martin ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Two Minor (Possible) Bugs
I did a lot of OSG fiddling over the weekend and came up with a few bugs (1 of which is definitely a bug and 1 of which might be); I wanted to try and get these in before 2.0 is released, but it may be too late. 1) I can crash any application that uses a Trackball Manipulator (as of svn update about an hour ago) by pressing and releasing the left mouse button _immediately_ followed by a spacebar press; this seems to be a timing/race issue, as it only happens when you do the sequence quickly. Sometimes it takes 5-10 seconds of doing it, but it will eventually happen. If all else fails, just go crazy pressing both and it'll happen. :) I'll build a debug release of OSG sometime later today and run it under valgrind to see exactly where it happens, but release builds in valgrind say the crash occurs in handle(), which isn't very helpful, as you can imagine... 2) GraphicsContext puts className(), libraryName(), etc. into a protected namespace, but GraphicsWindowEmbedded doesn't override them. Perhaps this is encouragement not to use this class? :) (I know the general idea is to avoid it's use, so this might be on purpose...) It's unlike me to report bugs without patches, but I've been trying to learn about and get my head around picking this weekend, and haven't had a chance to really investigate these things. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Pick
On Tue, 2007-06-12 at 16:52 +0200, [EMAIL PROTECTED] wrote:
Dear All
I implemented a Picking function...
In order to debug the picking function I simply print in monitor the id of
the picked drawable.
The problem is that the picking function is called two time for each mouse
click.
I don't think your picking function is getting called twice--I think
you're seeing the same object twice in your pick results, which is
something I'm running into myself. I just started learning picking this
weekend, so I'm not 100% sure what's going on, but perhaps someone else
will be able to chime in and help us both.
I originally suspected this had something to do with having a 2D HUD
Camera in my scene, but I don't think that's it.
Does anyone know why it happens?
This in my handler:
class PickHandler : public osgGA::GUIEventHandler {
public:
PickHandler(osgProducer::Viewer* viewer, Player* player):
_viewer(viewer),
_player(player){}
~PickHandler() {}
bool handle(const osgGA::GUIEventAdapter ea,osgGA::GUIActionAdapter us);
virtual void pick(const osgGA::GUIEventAdapter ea);
protected:
osgProducer::Viewer* _viewer;
Player* _player;
};
bool PickHandler::handle(const osgGA::GUIEventAdapter
ea,osgGA::GUIActionAdapter)
{
if( ea.getEventType() == osgGA::GUIEventAdapter::PUSH ) {
if( ea.getButton() == osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON
) pick(ea);
if( ea.getButton() ==
osgGA::GUIEventAdapter::RIGHT_MOUSE_BUTTON ) _player-MoveToNextUpLevel();
}
return false;
}
void PickHandler::pick(const osgGA::GUIEventAdapter ea)
{
osgUtil::IntersectVisitor::HitList hlist;
if (_viewer-computeIntersections(ea.getX(),ea.getY(),hlist))
{
for(osgUtil::IntersectVisitor::HitList::iterator hitr=hlist.begin();
hitr!=hlist.end();
++hitr)
{
std::ostringstream os;
if (hitr-_geode.valid() !hitr-_geode-getName().empty())
{
// the geodes are identified by name.
osg::ref_ptrNodeInfo cellInfo =
dynamic_castNodeInfo*
(hitr-_geode-getParent(0)-getParent(0)-getParent(0)-getUserData() );
int id_time = cellInfo-GetTime();
std::string id_cell = cellInfo-GetCellID();
_player-CellPicked(id_cell, id_time);
}
else if (hitr-_drawable.valid())
{
osObject
\hitr-_drawable-className()\std::endl;
}
}
}
}
.and this add it to the viewer
viewer-getEventHandlerList().push_front(new PickHandler(viewer.get(),
this));
Thanks
--
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Two Minor (Possible) Bugs
On Tue, 2007-06-12 at 16:13 +0100, Robert Osfield wrote: Hi Jeremy, Bug 1. Impressive... Impressively daft keyboard/mouse wizzardary :-) My guess is that the bug isn't actually related to TrackballManipulator, it just happens to be the thing in the way when things start falling apart. In theory the bulk event handling should Well, I couldn't get it to happen no matter how hard I tried if I used any of the other manipulators (Drive or Flight, although it does happen with the NodeTracker--but it uses some Trackball code). I do agree however that it could still be a red herring. all be done single threaded, there shouldn't be any race condition, for instance the call to handle() should certainly be single threaded. So.. this leaves me wondering if the GraphicsWindow event handling on your platform is the source of the problem and something is being tripped up due to the frantic event activity. BTW what platform are you working on? The only platform I know anything about is Linux. I used Wieblen's Win32 installer this weekend on my XP partition, but I felt dirty inside for a few minutes after. :) How can _anyone_ get anything done on Windows? :) Another note, you won't find me chasing this bug, I have RSI so no frantic activity on the mouse. I'll get Martin to go mad at the keyboard mouse though to see if we recreate the problem. Item 2) The className() and libraryName() should be public, so I've changed this in the GraphicsContext, GraphicsWindow and its subclasses. These changes shouldn't have too much of effect on the world though, as you don't generally serialize GraphicsWindow objects. This changes are now checked in. The only reason I spotted it was from using my ref_ptr wrapper, which attempts to find out what class/lib a failed operator-() comes from. Robert. On 6/12/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: I did a lot of OSG fiddling over the weekend and came up with a few bugs (1 of which is definitely a bug and 1 of which might be); I wanted to try and get these in before 2.0 is released, but it may be too late. 1) I can crash any application that uses a Trackball Manipulator (as of svn update about an hour ago) by pressing and releasing the left mouse button _immediately_ followed by a spacebar press; this seems to be a timing/race issue, as it only happens when you do the sequence quickly. Sometimes it takes 5-10 seconds of doing it, but it will eventually happen. If all else fails, just go crazy pressing both and it'll happen. :) I'll build a debug release of OSG sometime later today and run it under valgrind to see exactly where it happens, but release builds in valgrind say the crash occurs in handle(), which isn't very helpful, as you can imagine... 2) GraphicsContext puts className(), libraryName(), etc. into a protected namespace, but GraphicsWindowEmbedded doesn't override them. Perhaps this is encouragement not to use this class? :) (I know the general idea is to avoid it's use, so this might be on purpose...) It's unlike me to report bugs without patches, but I've been trying to learn about and get my head around picking this weekend, and haven't had a chance to really investigate these things. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Pick
On Tue, 2007-06-12 at 11:56 -0400, Robert Nitti wrote: Hi -- 'Picking' creates an osg::LineSegment that will intersect your scene... all the way through. So if you have (for example) a box shape, and you are picking one side, it's very possible (in fact, almost certain, unless you've done something special to prevent it) that the list of pick items will return the opposite side to you also; so you are correct Jeremy in saying that you can pick the same object twice. I've created my own post-filter to clean-up the list of drawables and geodes so that I don't treat them twice. Is this code you would have permission to post here or attach to a response? :) I'd be very interested to see optimized versions of such an operation... I hope this helps. Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy L. Moles Sent: Tuesday, June 12, 2007 10:59 AM To: osg users Subject: Re: [osg-users] Pick On Tue, 2007-06-12 at 16:52 +0200, [EMAIL PROTECTED] wrote: Dear All I implemented a Picking function... In order to debug the picking function I simply print in monitor the id of the picked drawable. The problem is that the picking function is called two time for each mouse click. I don't think your picking function is getting called twice--I think you're seeing the same object twice in your pick results, which is something I'm running into myself. I just started learning picking this weekend, so I'm not 100% sure what's going on, but perhaps someone else will be able to chime in and help us both. I originally suspected this had something to do with having a 2D HUD Camera in my scene, but I don't think that's it. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Settings for dual monitors on Linux
On Tue, 2007-06-12 at 13:48 -0400, Jean-Sébastien Guay wrote: Hello, A little OT, but I was hoping someone could help me with this. When I run osgviewer on my dual monitor Linux machine, it comes up as if it wanted to be on both screens but only displays on the left one (i.e. the object seems to be centered on the break between monitors, but I only get the osgviewer image on the left monitor). If I press 'f', it first goes to windowed mode, which works fine (I can move the window to both monitors and it seems to run at the same speed), then pressing 'f' again it goes to full screen on one monitor (the one where the window is currently, with the object centered in the monitor) and finally another 'f' gets it fullscreen across both monitors. At that point, it really is on both monitors, so it's only on startup that it seems to think it's on both but only displays on one... My system: AMD Athlon 1600+, 1GB RAM nVidia GeForce 5200 (I know, old, but that's what I have at the university for now) My xorg.conf contains this (among other things), I don't know if it's ok or not... Section Device Identifier Videocard0 Driver nvidia Option AddARGBGLXVisuals True Option DisableGLXRootClipping True Option TwinView Option MetaModes 1280x1024,1280x1024; 1280x1024; 1024x768,1024x768; 1024x768 Option TwinViewOrientation RightOf Option SecondMonitorHorizSync UseEdidFreqs Option SecondMonitorVertRefresh UseEdidFreqs EndSection Try adding: Option ConnectedMonitor DFP, CRT ...or whatever you combination of monitors is (Maybe DFP, DFP). I would appreciate any help on this. Also, should there be a command-line option to start osgviewer in a given screen mode (fuillscreen, window, span both monitors)? I can't seem to find it. Thanks, J-S ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgViewer::computeIntersections w/ NodePath
Sorry to be so verbose today (lots of posts!) I'm trying to come up with a good way to pick HUD elements from my scene. I'm using a very basic camera-in-camera setup, where my main camera is abstracted in osgViewer and my HUD camera is an ortho camera attached to a Group. This is really straightforward and demonstrated in many examples, so I'm pretty sure I'm not doing anything wrong as far as setup is concerned (though I can't be sure). I can use computeIntersections on the entire scene and it works exactly as advertised; both my HUD elements and objects in the 3D scene. The problem, as it so often is, arises from a destire to optimize. What I want to do is only run computeIntersections on anything attached to my HUD camera. I believe the method for doing this (which I have tried to confirm by searching the list archives) is to run computeIntersections with a NodePath reference, which I can get using getParentalNodePaths. My question is: what is the proper way to create the NodePath to achieve the desired functionality? I've tried using: _uiCamera-getParentalNodePaths()[0] ...but this doesn't seem to work at all. What I suspect I'm missing is either some setup code before computerIntersections with regards to the orthographic projection or perhaps I'm misunderstanding the purpose of the NodePath version of computerIntersections and it's usefulness in HUD picking. I thought an alternative might be to use a NodeMask, having one mask for my UI elements and another mask for everything else. As long as the uiCamera also had this mask--and was very high up in the graph--this might be another fast option, right? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgViewer::computeIntersections w/ NodePath
On Tue, 2007-06-12 at 21:08 +0100, Robert Osfield wrote: NodeMask/ TraversalMask combination is how I'd tackle this. Simple, easy--works for me. :) Sometimes all you need is a respected second opinion! On 6/12/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: Sorry to be so verbose today (lots of posts!) I'm trying to come up with a good way to pick HUD elements from my scene. I'm using a very basic camera-in-camera setup, where my main camera is abstracted in osgViewer and my HUD camera is an ortho camera attached to a Group. This is really straightforward and demonstrated in many examples, so I'm pretty sure I'm not doing anything wrong as far as setup is concerned (though I can't be sure). I can use computeIntersections on the entire scene and it works exactly as advertised; both my HUD elements and objects in the 3D scene. The problem, as it so often is, arises from a destire to optimize. What I want to do is only run computeIntersections on anything attached to my HUD camera. I believe the method for doing this (which I have tried to confirm by searching the list archives) is to run computeIntersections with a NodePath reference, which I can get using getParentalNodePaths. My question is: what is the proper way to create the NodePath to achieve the desired functionality? I've tried using: _uiCamera-getParentalNodePaths()[0] ...but this doesn't seem to work at all. What I suspect I'm missing is either some setup code before computerIntersections with regards to the orthographic projection or perhaps I'm misunderstanding the purpose of the NodePath version of computerIntersections and it's usefulness in HUD picking. I thought an alternative might be to use a NodeMask, having one mask for my UI elements and another mask for everything else. As long as the uiCamera also had this mask--and was very high up in the graph--this might be another fast option, right? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Settings for dual monitors on Linux
On Tue, 2007-06-12 at 14:22 -0600, Paul Martz wrote: I would appreciate any help on this. Also, should there be a command-line option to start osgviewer in a given screen mode (fuillscreen, window, span both monitors)? I can't seem to find it. osgviewer --screen 0 cow.osg should open only on display 0. --screen 1 should open on display 1. Not exactly what you wanted, but a step in the right direction. (This is with OSG v1.9.x/2.0.) (Interesting post... I recently obtained a second monitor for my Linux box w/ NVIDIA card. Of course it doesn't just use it by default, so I went to boot the system to tweak the necessary X config files, and the system suddenly would not boot, complaining that it couldn't load the NVIDIA driver... This is before I made any changes at all. It's as if the mere -presence- of the 2nd monitor in the room caused the system to refuse to boot :-)... So, first I'll need to figure out why it doesn't boot, then I can work on configuring it for two monitors...) Well, what we tell our customers (and what I use myself) is just to simply run the nvidia-settings GUI; you can dynamically configure any currently detected monitors using that app, and it'll even offer to write a proper xorg.conf for you to steal from if necessary. (You'll need a 97**+ series driver, but it's all there) When xrandr1.2 support is added in future NVidia versions, it'll be a squashed issue; joyous day! Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] 3rd Person Camera Solutions
I'm trying to put together a standard 3rd Person camera setup, and it appears that the NodeTrackerManipulator demonstrated in osgsimulation is a great place to begin. Am I correct in my assumption that this Manipulator can be made to instruct a Camera to follow whatever Node it is attched to as the object is translated? I haven't had a chance to test this out yet, and I'm not sure if the planet is spinning or the cessna is moving in osgsimulation. :) My main question, however, is a request for any existing solutions to this before I being reinventing the wheel--as educational as that may be. :) I guess it's a tough thing to answer, since the Manipulator classes seem to be quite dependent on the windowing system/viewer in question (in my case, SDL). However, any advice or success stories would be helpful. The one thing in particular I'll be interested in doing is disabling the requestContinuousUpdate() feature of the TrackballManipulator (which the NodeTrackerManipulator appears to use internally) so that it behaves as close to modern game cameras as possible... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] 3rd Person Camera Solutions
On Fri, 2007-06-08 at 16:27 +0100, Robert Osfield wrote: Hi Jeremy, All of manipulators will work with all of the osgViewer, they aren't platform specific. The request* methods are really just hints to the viewer. Most games will being running a frame loop and won't be event driven so you won't ever be turning on/off the rendering, this means that such viewers will just ignore the request as the frame will be updated anyway. You'll see the vast majority of examples work with a frame loop. Is there a way, then, to disable the continuous trajectory (for lack of a better descriptive term) feature of the TrackballManipulator then? Or does this go against what it's meant to do in the first place? I'd like to leverage the existing code for sure, but perhaps this is a job for a different manipulator? Robert. On 6/8/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: I'm trying to put together a standard 3rd Person camera setup, and it appears that the NodeTrackerManipulator demonstrated in osgsimulation is a great place to begin. Am I correct in my assumption that this Manipulator can be made to instruct a Camera to follow whatever Node it is attched to as the object is translated? I haven't had a chance to test this out yet, and I'm not sure if the planet is spinning or the cessna is moving in osgsimulation. :) My main question, however, is a request for any existing solutions to this before I being reinventing the wheel--as educational as that may be. :) I guess it's a tough thing to answer, since the Manipulator classes seem to be quite dependent on the windowing system/viewer in question (in my case, SDL). However, any advice or success stories would be helpful. The one thing in particular I'll be interested in doing is disabling the requestContinuousUpdate() feature of the TrackballManipulator (which the NodeTrackerManipulator appears to use internally) so that it behaves as close to modern game cameras as possible... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] 3rd Person Camera Solutions
On Fri, 2007-06-08 at 20:35 +0200, Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy L. Moles wrote: Hmm, well, what do OSG users do when they want a Manipulator that stops moving the scene when you stop moving the mouse? Do they make a custom Manipulator? Am I missing something obvious? You remove the manipulator or switch to another one? This is what I do, I never had the need to hack the manipulator with some sort of kill switch. I've said twice in this thread that this may a job for a different manipulator (possibly a custom one written by the user). My point is, I couldn't find a Manipulator already in OSG that does it, and it seems like a simple enough thing to enable in an existing MatrixManipulator to prevent creating another subclass that only differs in this respect (indeed, they all end up having to reproduce a lot of the event parsing code that might actually be able to be shared with some modification). The Trackball Manipulator already has all the logic you need, you just need to disable what it refers to as throwing (not sure what the term means, but it's the variable name. :)) Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGaaFWn11XseNj94gRAjP1AJ9OqlzL9PK3LaJPEHPpRs91QmuCogCePFOY Sf4BmvjnSwwOJu40QTfuchA= =/PdV -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgdepthshadow loses hardware acceleration
On Fri, 2007-06-08 at 11:49 -0600, Paul Martz wrote: Hi folks -- I'm on a Windows system with an NVIDIA GeForce 6600 and 91.31 drivers (yes, a little out-of-date). I have the system configured for Dualview on two monitors. If I run osgdepthshadow, by default it comes up spanning both displays. However, there is no hardware acceleration; the framerate is about 1Hz. If I hack the code and call viewer.setUpOnSingleScreen( 0 ), osgdepthshadow renders on one monitor with full hardware acceleration. Has anyone else experienced this? Any ideas why the driver falls back to the software path when spanning both displays? Other examples run fine spanning both displays... With the preface that I know absolutely JACK about Windows: I had something like this happen on my Windows XP partition and was able to fix by disabling NVidia's video overlay or something like that in their GUI config app. Not sure if it'll help you, though. Hopefully. :) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] 3rd Person Camera Solutions
On Fri, 2007-06-08 at 14:52 -0400, Jeremy L. Moles wrote: On Fri, 2007-06-08 at 20:35 +0200, Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy L. Moles wrote: Hmm, well, what do OSG users do when they want a Manipulator that stops moving the scene when you stop moving the mouse? Do they make a custom Manipulator? Am I missing something obvious? You remove the manipulator or switch to another one? This is what I do, I never had the need to hack the manipulator with some sort of kill switch. I've said twice in this thread that this may a job for a different Oops, sorry, this came off way more rude than I meant for it to! :) Not my intention... manipulator (possibly a custom one written by the user). My point is, I couldn't find a Manipulator already in OSG that does it, and it seems like a simple enough thing to enable in an existing MatrixManipulator to prevent creating another subclass that only differs in this respect (indeed, they all end up having to reproduce a lot of the event parsing code that might actually be able to be shared with some modification). The Trackball Manipulator already has all the logic you need, you just need to disable what it refers to as throwing (not sure what the term means, but it's the variable name. :)) Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGaaFWn11XseNj94gRAjP1AJ9OqlzL9PK3LaJPEHPpRs91QmuCogCePFOY Sf4BmvjnSwwOJu40QTfuchA= =/PdV -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Interesting ref_ptr Derivitive
Hello all.
I've attached a small bit of purely fun code I came up with last night
demonstrating an implementation of osg::ref_ptr (in the form of
osg::Pointer) that tries to determine, upon attempting to invoke a
method on a null pointer, what kind of object threw the error. It uses a
real nasty hack to do so, but it's still kind of interesting. :)
Basically, if you define OSG_POINTER, the derived class will overload
operator-() and do some error checking. Otherwise, the Pointer class
will just be a tiny shim over the real osg::ref_ptr.
Anyways, this is just for informational purposes. *grin*
#include sstream
#include exception
#include osg/ref_ptr
#include osg/notify
namespace osg {
// If the user defines OSG_POINTER, use our custom implementation that is a bit
// slower but more verbose. :)
#ifdef OSG_POINTER
// I like the ref_ptr, but I'd like a version that throws an exception when you
// try and call a method on something that is set to 0.
template typename T
class Pointer: public osg::ref_ptrT {
public:
Pointer(): osg::ref_ptrT() {}
Pointer(T* ptr): osg::ref_ptrT(ptr) {}
Pointer(const Pointer rp): osg::ref_ptrT(rp) {}
T* operator-() {
// The following code is a super-dirty hack that allows us to try and get
// the class name of the object that the ref_ptr failed on. We do it by
// attemping to actually create a good one ourselves and invoke className()
// and libraryName on it.
if(not osg::ref_ptrT::valid()) {
std::stringstream error;
error You tried to call a method on a null Pointer of type ;
try {
osg::ref_ptrT t = new T();
error t-libraryName() :: t-className();
}
catch(std::bad_alloc) {
error UNKNOWN! (std::bad_alloc);
}
error
. This probably means you forgot to actually create the
object, and just have the Pointer around. Unfortunately, I
can't actually determine WHERE the error took place.
;
osg::notify(osg::FATAL) error.str() std::endl;
// This is my own exception class; won't work in this context.
// throw Exception(error.str().c_str());
throw std::exception();
}
else return osg::ref_ptrT::operator-();
}
};
// Otherwise, just use a lightweight wrapper around the real osg::ref_ptr.
#else
template typename T
class Pointer: public osg::ref_ptrT {
public:
Pointer(): osg::ref_ptrT() {}
Pointer(T* ptr): osg::ref_ptrT(ptr) {}
Pointer(const Pointer rp): osg::ref_ptrT(rp) {}
};
#endif
}
#endif
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Off Topic / OpenGL Texture Tiling
I've tried googling and asking this question in various other OpenGL places with no success--so I figured I'd try here, since I know there are some OpenGL gurus around. In fact, I was told in #opengl on Freenode it wasn't possible, but I doubt it sense people have been doing this for ages used fixed-function OpenGL. I'm working on a UI toolkit using native OSG objects (no weird gluecode or external library) and have come across something I can't readily get the answer to. Imagine an interface window; at the minimum you'll have about 9 regions that describe this window: - upper left and right corners - lower left and right corners - top, left, bottom, and right bars - center Now imagine a texture you want to use as the window's skin. Ideally, you'll load an image into the texture and position the TexCoords so that you can create the illusion of having a true, decorated and composed window. This is fairly straightforward in concept except for one aspect. Lets say you want to texture the top bar region of your window. Well, by default, unless this portion of your image (or skin) is cleverly positioned in the texture itself, there's really no way I know of to tile it across the geometry. You can stretch it across, but this is often quite ugly. My question: is it possible in OpenGL to somehow manipulate the texture matrix (or something else) to only operate on a sub-region of a texture such that you can tile just that portion? CEGUI does this somehow, but it's API is so abstracted I can't really track it's implementation down. I _know_ it's possible using a GLSL shader, but at this point it's really academic for me to find out how to do it otherwise, I know game makers have been doing this for years w/out shaders, and it's really bugging me to find out how! :) Any advice or guidance on the issue would be enormously appreciated... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Off Topic / OpenGL Texture Tiling
On Wed, 2007-06-06 at 21:06 +0100, Robert Osfield wrote: Hi Jeremy, OpenGL supports texture repeat but only for the whole texture, osgtexture2D has an example of texture repeat so have a look at whats possible with just standard OpenGL wrap modes. C'mon, I at least knew this much! *grin* Repeating a sub-porton of texture atlas is rather different though, using wrap modes you'll end up repear over the whole 0.0 to 1.0 range rather than just the portion you want. If you using a TextMat you can get OpenGL to repeat the texture at high frequency, but it'll still be over the whole 0.0 to 1.0 range, it won't skip things out of your range. The only ways I can think of repeating a subporting are to use GLSL to manage the tex coord wrapping internally in the fragment program, or to simply repeat your texture manually in your texture atlas, or just ditch the use of sub regions and wash, rinse, repeat like standard OpenGL texture wrap modes. Yeah, this is what I suspected. It still kinda' raises the question how other kits do it, but I bet it's something like this: Here's my window's conceptual top bar: +---+--+---+ | 1 | 1 | 3 | +---+--+---+ ...and I bet this is theirs: +---+---+---+---+---+---+---+---+---+---+ | 1 | . | . | . | . | . | . | . | . | 3 | +---+---+---+---+---+---+---+---+---+---+ ...where they've created new geometry to accommodate for being unable to tile only a portion of a texture. I think there's a Linux OpenGL tool that will let me force anything being rendered in OpenGL to be in wireframe... I'll snoop a bit and confirm... Robert. On 6/6/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: I've tried googling and asking this question in various other OpenGL places with no success--so I figured I'd try here, since I know there are some OpenGL gurus around. In fact, I was told in #opengl on Freenode it wasn't possible, but I doubt it sense people have been doing this for ages used fixed-function OpenGL. I'm working on a UI toolkit using native OSG objects (no weird gluecode or external library) and have come across something I can't readily get the answer to. Imagine an interface window; at the minimum you'll have about 9 regions that describe this window: - upper left and right corners - lower left and right corners - top, left, bottom, and right bars - center Now imagine a texture you want to use as the window's skin. Ideally, you'll load an image into the texture and position the TexCoords so that you can create the illusion of having a true, decorated and composed window. This is fairly straightforward in concept except for one aspect. Lets say you want to texture the top bar region of your window. Well, by default, unless this portion of your image (or skin) is cleverly positioned in the texture itself, there's really no way I know of to tile it across the geometry. You can stretch it across, but this is often quite ugly. My question: is it possible in OpenGL to somehow manipulate the texture matrix (or something else) to only operate on a sub-region of a texture such that you can tile just that portion? CEGUI does this somehow, but it's API is so abstracted I can't really track it's implementation down. I _know_ it's possible using a GLSL shader, but at this point it's really academic for me to find out how to do it otherwise, I know game makers have been doing this for years w/out shaders, and it's really bugging me to find out how! :) Any advice or guidance on the issue would be enormously appreciated... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] State of Collada Plugin Build?
On Sun, 2007-06-03 at 21:36 -0700, [EMAIL PROTECTED] wrote: The new make rules are available in the latest DOM code available on SourceForge (instructions for obtaining are here). This will go into the next DOM release. Well, you're right of course--there is now a make install rule; however: 1) It doesn't allow you to specify a PREFIX of any sort. I certainly don't put anything in /usr that isn't a package, although I guess most people aren't as micro-managing as myself. Maybe this is something that could be done at a later date? 2) Purely out of curiosity, was the decision made not to put the Collada development headers in a namespace of their own (#include collada/dom.h) something done out of desire for maximum compatibility? It's just not what I'm used to seeing, to be quite honest; dom.h is pretty arbitrary, so I can conceive of a situation where a person would have difficulty trying to figure out that header include with no context. :) Anyway, it's great to know the Collada folks are still alive and kicking and available in some format for questions and whatnot. :) There's a DOM installer for Windows available on SourceForge, but it doesn't do exactly the same thing as the Linux make install rules. The Windows installer sets up some environment variables needed for building on Windows. The Linux make install puts the COLLADA DOM headers and libraries in /usr/include and /usr/lib. Robert Osfield wrote: Hi Steven, On 6/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Actually we did add 'install' and 'uninstall' targets to the COLLADA makefiles. When you install it copies the headers to /usr/include/collada and puts the libs in /usr/lib. Let me know if this is helpful or if you need something different. Which version of COLLADA is this install option available? Is there an install for Windows too? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] OSG Source svn:ignore
Robert, CMake currently creates upwards of about 150 files inside of the subversion project that are not known about or understood by it in any way (they're all temporary files). This can make it really difficult (in my opinion) to use many of the svn commands interactively or get a feel for the state of your current checkout. Would you be opposed to introducing svn:ignore properties for all of these files? It's not an uncommon or taboo practice; in fact, the feature is there to be used in this exact manner. Many people seem to have a kind of prejudice against it's use, but I believe it's only because they don't understand how it works. :) IF SO, I've taken the liberty of creating a very small Bash script that you can run while inside of the project that will do all the svn ps svn:ignore commands for you in the proper way (I tested it many times here). If not, well, maybe we can come up with some other of divorcing CMake's (necessary) bloat from the OSG source, if that kind of thing is important... cmake-ignore.sh Description: application/shellscript ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG Source svn:ignore
On Mon, 2007-06-04 at 11:32 -0400, Jeremy L. Moles wrote: Robert, CMake currently creates upwards of about 150 files inside of the subversion project that are not known about or understood by it in any way (they're all temporary files). This can make it really difficult (in my opinion) to use many of the svn commands interactively or get a feel for the state of your current checkout. Would you be opposed to introducing svn:ignore properties for all of these files? It's not an uncommon or taboo practice; in fact, the feature is there to be used in this exact manner. Many people seem to have a kind of prejudice against it's use, but I believe it's only because they don't understand how it works. :) IF SO, I've taken the liberty of creating a very small Bash script that you can run while inside of the project that will do all the svn ps svn:ignore commands for you in the proper way (I tested it many times here). If not, well, maybe we can come up with some other of divorcing CMake's (necessary) bloat from the OSG source, if that kind of thing is important... Also, I put this here rather than submissions in case other folks wanted to chime in with their opinions on whether this is a valid pursuit or not. :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG Source svn:ignore
On Mon, 2007-06-04 at 16:57 +0100, Robert Osfield wrote: Hi Jeremy, Thanks for the script, I'll have a look at it. I'm not opposed to using ingore. I'm still a bit of svn newbee so don't know all the features yet... learning slowly though :) W.r.t CMake putting temporary files everywhere, the easy answer to do out of source builds. i.e in the directory above OpenSceneGraph do: mkdir myBuild cd myBuild cmake ../OpenSceneGraph make Hmm, I reveal a bit of my CMake newbness when I say I had no idea this worked. :) In fact, the CMake project really seems to emphasize this kind of usage. This doesn't diminish the usefulness of ingore though. Agreed, but the above might be another solution (especially on Linux, where it's easy to do this kind of thing; I'm not entirely sure about Windows). Another thing to remember, though, is that's it's _very_ easy to, in the future if you abandon CMake, unset these svn:ignore properties on the directories... Robert. On 6/4/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: Robert, CMake currently creates upwards of about 150 files inside of the subversion project that are not known about or understood by it in any way (they're all temporary files). This can make it really difficult (in my opinion) to use many of the svn commands interactively or get a feel for the state of your current checkout. Would you be opposed to introducing svn:ignore properties for all of these files? It's not an uncommon or taboo practice; in fact, the feature is there to be used in this exact manner. Many people seem to have a kind of prejudice against it's use, but I believe it's only because they don't understand how it works. :) IF SO, I've taken the liberty of creating a very small Bash script that you can run while inside of the project that will do all the svn ps svn:ignore commands for you in the proper way (I tested it many times here). If not, well, maybe we can come up with some other of divorcing CMake's (necessary) bloat from the OSG source, if that kind of thing is important... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG Source svn:ignore
On Mon, 2007-06-04 at 17:13 +0100, Robert Osfield wrote: Hi Jeremy, Is it possible to set svn to generally ignore CMake files? It seems individually setting ignore is a bit overkill, and not helpful for when you create new directories. I've just scanned the online svn book and it looks like it should be possible, but its not entirely clear what steps I need to take. I wish I had more time to go learn it properly... If my understanding is correct (and I'm pretty sure it is), there isn't a global way to ignore any groups of files in the project itself. Each user can edit ~/.subversion/config to artificially ignore them, but it's only per-user (which may be all we need, really). You might be able to create an svn auto-props rule that says something like: Every time I create a new directory, set these properties foo and bar on it. ...but I don't think you can put a rule in the root of a project and have it recursively modify every directory therein, not when SVN treats each directory as it's own thing and nothing is really designed to traverse upwards through the tree (as far as I'm aware?). Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: And svn:eol-style, too (was: RE: [osg-users] OSG Source svn:ignore)
On Mon, 2007-06-04 at 10:28 -0600, Paul Martz wrote: While we're talking about SVN properties, I'll repeat my request to set the svn:eol-style property to 'native' on all the CMakeLists.txt files. This would really make it easier for Windows users to view and modify the CMakeLists.txt files. As far as I know, this will need to be set on each file individually with svn propset, probably easy to automate with a script. Setting autoprops in the SVN server configuration file to set this property for *.txt files would be a good solution for future additions. This would be pretty easy: for F in $(find . -name CMakeLists.txt); do svn ps svn:eol-style native $F done ...but I wonder, why stop there? I think with a bit of testing, I could provide Robert with a proper ~/.subversion/config file that would automatically set this on all of our source files and set the ignores on the directories that he adds. Thanks, -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy L. Moles Sent: Monday, June 04, 2007 9:32 AM To: osg users Subject: [osg-users] OSG Source svn:ignore Robert, CMake currently creates upwards of about 150 files inside of the subversion project that are not known about or understood by it in any way (they're all temporary files). This can make it really difficult (in my opinion) to use many of the svn commands interactively or get a feel for the state of your current checkout. Would you be opposed to introducing svn:ignore properties for all of these files? It's not an uncommon or taboo practice; in fact, the feature is there to be used in this exact manner. Many people seem to have a kind of prejudice against it's use, but I believe it's only because they don't understand how it works. :) IF SO, I've taken the liberty of creating a very small Bash script that you can run while inside of the project that will do all the svn ps svn:ignore commands for you in the proper way (I tested it many times here). If not, well, maybe we can come up with some other of divorcing CMake's (necessary) bloat from the OSG source, if that kind of thing is important... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] State of Collada Plugin Build?
I hope folks are reading this thread because this is good stuff. :) Thanks for the updates, Steven! On Mon, 2007-06-04 at 11:34 -0700, [EMAIL PROTECTED] wrote: Jeremy L. Moles wrote: On Sun, 2007-06-03 at 21:36 -0700, [EMAIL PROTECTED] wrote: The new make rules are available in the latest DOM code available on SourceForge (instructions for obtaining are here). This will go into the next DOM release. Well, you're right of course--there is now a make install rule; however: 1) It doesn't allow you to specify a PREFIX of any sort. I certainly don't put anything in /usr that isn't a package, although I guess most people aren't as micro-managing as myself. Maybe this is something that could be done at a later date? Good point. I submitted bug 1730906 in SourceForge on this: http://sourceforge.net/tracker/index.php?func=detailaid=1730906group_id=157838atid=805424 2) Purely out of curiosity, was the decision made not to put the Collada development headers in a namespace of their own (#include collada/dom.h) something done out of desire for maximum compatibility? It's just not what I'm used to seeing, to be quite honest; dom.h is pretty arbitrary, so I can conceive of a situation where a person would have difficulty trying to figure out that header include with no context. :) I think you have an old version of the makefile. I updated it to put the headers in /usr/include/collada instead of just /usr/include, although the libs still go in /usr/lib. I think most libraries on my machine are just in /usr/lib instead of in a subdirectory of /usr/lib. I also added an 'uninstall' rule. Anyway, it's great to know the Collada folks are still alive and kicking and available in some format for questions and whatnot. :) Hah, yeah, we're still around. I'm the new maintainer of the Collada DOM. I'll read anything going to osg-users that has 'collada' in the title. For some reason, Thunderbird won't let me filter on the message body. There's a DOM installer for Windows available on SourceForge, but it doesn't do exactly the same thing as the Linux make install rules. The Windows installer sets up some environment variables needed for building on Windows. The Linux make install puts the COLLADA DOM headers and libraries in /usr/include and /usr/lib. Robert Osfield wrote: Hi Steven, On 6/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Actually we did add 'install' and 'uninstall' targets to the COLLADA makefiles. When you install it copies the headers to /usr/include/collada and puts the libs in /usr/lib. Let me know if this is helpful or if you need something different. Which version of COLLADA is this install option available? Is there an install for Windows too? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgviewer Camera Animation (preliminary)
On Fri, 2007-06-01 at 11:35 +0100, Robert Osfield wrote: Thanks Jeremy, I've merged the new handler and checked it in. Oh, cool. :) I was going to submit it in the official way though, since I know you'd rather not work w/ diffs... I have changed its name to RecordCameraPathHandler, and have also change it to write to saved_animation.path as per the old osgProducer::Viewer. I have removed the use of getCameraWithFocus() as this could cause problems when you have multiple windows open with multiple slave cameras, when you should just record the master cameras path. I haven't added in the 'Z' functionality suggested by Paul yet though, this is a little more complicated because osgViewer::Viewer isn't hard wired to use a KeySwitchMatrixManipulator like osgProducer::Viewer was. What will need to be done is for a check against the Viewer::getCameraManipulator() to see if it is a KeySwitchMatrixManipulator, if not then insert one, and add this original manipulator plus an AnimationPathManipulator, then switching this to current selected one. Alrighty--this will be my next task, then. Robert. On 5/31/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: I put this together during lunch today if anyone is interested in trying it out (I'll submit formal files when it's done, Robert). Basically, it tries to emulate the old osgProducer camera animation functionality (which we've been discussing in another thread). It is a patch against SVN as of a few minutes ago (May 31st, 16:30 EST) It seems to be working okay for me at the moment. Usage is: # OSG_CAMERA_ANIMATION_FPS=25 osgviewer cow.osg ...press Z... ...move camera... ...press Z again... # vim camera-path.txt ...awesomeness!... # osgviewer -p camera-path.txt cow.osg In the example above I explicitly set the FPS to 25, although this is the default. It doesn't seem to need a high ControlPoint capture value, since it appears to do smooth interpolation between them... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] State of Collada Plugin Build?
Back on May 4th Robert posted about trying to get the Collada plugin to build with CMake cleanly--was this ever accomplished? If someone can tell me how, I'll update the README in the dae plugin, but as it currently stands it appears to be woefully broken. :( I've tried everything I can think (granted, I'm no CMake wizard), but nothing works. Eventually, I just wrote a bash script to do it for me, which works just fine. However, if a user can't simply use ccmake to either: 1) Build it right. 2) Give the user some hint WHY it can't build it right. ...I'd have to say it's not working as intended. It doesn't help that the Collada project has absolutely no concept of a make install or similar, so perhaps this entire subject warrants a big osg.com/wiki/DAE node or similar, since I think this question pops up pretty frequently. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Recording an AnimationPath in osgviewer
On Thu, 2007-05-31 at 15:02 +0100, Robert Osfield wrote: On 5/31/07, Paul Martz [EMAIL PROTECTED] wrote: Apparently my confusion stemmed from the fact that I thought we were discussing a solution in the osgviewer application. This seemed like the logical place to me, given that the analogous playback support is located in the osgviewer app. However, given that osgProducer had record support embedded, then perhaps osgViewer is the better choice for location. Embedding path support into osgViewer::Viewer is certainly the wrong approach, the right approach is to have a non intrusive event handler, one defined in include/osgViewer/ViewerEventHandlers like the WindowSizeHandler etc. The little bit of extra complexity with recording the path is just ensuring that you have the current frames final view matrix. If you don't mind recording the previous frames view matrix then the event handler could catch frame events and then simply do a View.getCamera()-getViewMatrix(). As a first step this would be the thing to do. Alrighty! :) This is actually pretty straightforward, and shouldn't be too hard at all. If it's okay, I'd like to take a hack at this. If for some reason I can't crack it, I'll send another e-mail tomorrow morning... Would you be opposed to having some kind of visual indicator in osgviewer that the camera path was currently being recorded? Maybe a small bit of text in the bottom left screen, or perhaps a red circle? The next step would be to add a callback to the Viewer to catch the view matrix prior to the final renderingTraversals() call, this is where a RenderinTraversalsCallback would come in, it could catch the renderinTraversals() call, get the current View matrix and then issue the final renderinTraversalsImplementation() call. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgviewer Camera Animation (preliminary)
I put this together during lunch today if anyone is interested in trying
it out (I'll submit formal files when it's done, Robert). Basically, it
tries to emulate the old osgProducer camera animation functionality
(which we've been discussing in another thread). It is a patch against
SVN as of a few minutes ago (May 31st, 16:30 EST)
It seems to be working okay for me at the moment. Usage is:
# OSG_CAMERA_ANIMATION_FPS=25 osgviewer cow.osg
...press Z...
...move camera...
...press Z again...
# vim camera-path.txt
...awesomeness!...
# osgviewer -p camera-path.txt cow.osg
In the example above I explicitly set the FPS to 25, although this is
the default. It doesn't seem to need a high ControlPoint capture value,
since it appears to do smooth interpolation between them...
Index: include/osgViewer/ViewerEventHandlers
===
--- include/osgViewer/ViewerEventHandlers (revision 6793)
+++ include/osgViewer/ViewerEventHandlers (working copy)
@@ -14,6 +14,7 @@
#ifndef OSGVIEWER_VIEWEREVENTHANDLER
#define OSGVIEWER_VIEWEREVENTHANDLER 1
+#include osg/AnimationPath
#include osgGA/GUIEventHandler
#include osgViewer/GraphicsWindow
@@ -102,6 +103,36 @@
bool_done;
};
+/**
+Handler allowing the user to record the animation path of a camera. In it's current
+implementation, this handler cannot guarantee the final view matrix is correct; it is
+conceivable that the matrix may be one frame off. Eh--not a big deal! :)
+TODO: Find the good filename.
+TODO: Write as we go, not when it's all done.
+TODO: Create osgviewer on-screen indication that animation is taking place.
+TODO: Explore multi-cameras thing.
+TODO: Investigate crash if non-focused camera?
+*/
+class AnimationPathHandler : public osgGA::GUIEventHandler
+{
+public:
+
+AnimationPathHandler();
+
+virtual void getUsage(osg::ApplicationUsage usage) const;
+
+bool handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter aa);
+
+protected:
+
+bool _currentlyRecording;
+double _interval;
+double _delta;
+osg::Timer_t _animStartTime;
+osg::Timer_t _lastFrameTime;
+osg::ref_ptrosg::AnimationPath _animPath;
+};
+
}
#endif
Index: applications/osgviewer/osgviewer.cpp
===
--- applications/osgviewer/osgviewer.cpp (revision 6793)
+++ applications/osgviewer/osgviewer.cpp (working copy)
@@ -117,6 +117,9 @@
// add the help handler
viewer.addEventHandler(new osgViewer::HelpHandler(arguments.getApplicationUsage()));
+// add the camera path handler
+viewer.addEventHandler(new osgViewer::AnimationPathHandler);
+
while (arguments.read(--SingleThreaded)) viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
while (arguments.read(--CullDrawThreadPerContext)) viewer.setThreadingModel(osgViewer::Viewer::CullDrawThreadPerContext);
while (arguments.read(--DrawThreadPerContext)) viewer.setThreadingModel(osgViewer::Viewer::DrawThreadPerContext);
Index: src/osgViewer/ViewerEventHandlers.cpp
===
--- src/osgViewer/ViewerEventHandlers.cpp (revision 6793)
+++ src/osgViewer/ViewerEventHandlers.cpp (working copy)
@@ -11,6 +11,7 @@
* OpenSceneGraph Public License for more details.
*/
+#include fstream
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
@@ -342,4 +343,95 @@
return false;
}
+AnimationPathHandler::AnimationPathHandler():
+_currentlyRecording(false),
+_delta(0.0f),
+_lastFrameTime(osg::Timer::instance()-tick()),
+_animStartTime(0)
+{
+_animPath = new osg::AnimationPath();
+
+const char* str = getenv(OSG_CAMERA_ANIMATION_FPS);
+
+if(str) _interval = 1.0f / atof(str);
+
+else _interval = 1.0f / 25.0f;
}
+
+void AnimationPathHandler::getUsage(osg::ApplicationUsage usage) const
+{
+usage.addKeyboardMouseBinding(z, Toggle camera path recording.);
+}
+
+bool AnimationPathHandler::handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter aa)
+{
+osgViewer::Viewer* viewer = dynamic_castosgViewer::Viewer*(aa);
+
+if (viewer == NULL)
+{
+return false;
+}
+
+switch(ea.getEventType())
+{
+case(osgGA::GUIEventAdapter::KEYUP):
+{
+if (ea.getKey() == 'z')
+{
+// The user has requested to BEGIN recording. If there isn't a focused
+// Camera, ignore the key press.
+if (!_currentlyRecording viewer-getCameraWithFocus() != NULL)
+{
+_currentlyRecording = true;
+_animStartTime = osg::Timer::instance()-tick();
+}
+
+// THe user
RE: [osg-users] osgviewer Camera Animation (preliminary)
On Thu, 2007-05-31 at 15:11 -0600, Paul Martz wrote: Thanks, Jeremy. I appreciate your work on adding this capability back into OSG. My only comments are: * Use 'z' to start recording and 'Z' to stop and start playing back, like in the OSG 1.2 release. * Save the data to saved_animation.path like in the OSG 1.2 release. I'm not trying to be a jerk, I'm just trying to minimize needless changes so that users experience a smooth transition to 2.0. (And I'm trying to avoid changes to the documentation. :-) Haha, no need to explain, I understand. :) If it was me I'd just be like, MAKE IT SO! Again, thanks, -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy L. Moles Sent: Thursday, May 31, 2007 2:29 PM To: osg users Subject: [osg-users] osgviewer Camera Animation (preliminary) I put this together during lunch today if anyone is interested in trying it out (I'll submit formal files when it's done, Robert). Basically, it tries to emulate the old osgProducer camera animation functionality (which we've been discussing in another thread). It is a patch against SVN as of a few minutes ago (May 31st, 16:30 EST) It seems to be working okay for me at the moment. Usage is: # OSG_CAMERA_ANIMATION_FPS=25 osgviewer cow.osg ...press Z... ...move camera... ...press Z again... # vim camera-path.txt ...awesomeness!... # osgviewer -p camera-path.txt cow.osg In the example above I explicitly set the FPS to 25, although this is the default. It doesn't seem to need a high ControlPoint capture value, since it appears to do smooth interpolation between them... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Recording an AnimationPath in osgviewer
On Wed, 2007-05-30 at 16:35 +0100, Robert Osfield wrote: Hi Paul, Implementing the record of the animation path would be pretty straight forward to implement, if only I clone myself without the RSI and we'd have it already. It'd be much appreciated if someone else can jump in and implement a RecordCameraPathHandler :-) What would be the best way to do this? It looks like the file format is pretty straightforward... just attach an UpdateCallback to the camera in osgviewer and grab the world position and orientation every 1/25 of a second (I'm not entirely sure how Producer did it, so I'm sure there's probably a better way...) and dump this to a text file? Robert. On 5/30/07, Paul Martz [EMAIL PROTECTED] wrote: Hi OSGers -- As most of you are aware, the move from osgProducer to osgViewer means that the osgviewer application has lost its ability to record an AnimationPath. The first chapter of the OSG Quick Start Guide, written last November back when everything was osgProducer-based, documents recording an AnimationPath with osgvewer. I had hoped by now that this functionality would be added back into the application, as it's quite useful for testing, performance measurements, etc. But as the OSG v2.0 release nears, there seems to be no movement towards reimplementing this feature. What's the consensus of the community? Do others find this feature valuable? If so, will someone step up and reimplement it? Or should I yank this section from the Quick Start Guide? What I'd really like to avoid, of course, is yanking it for the next revision, and then a few weeks later, someone reimplements it, forcing a new revision with the yanked text added back in. Feedback on this feature, and how the QSG should handle it, is appreciated. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Dell ships Ubuntu preinstalled
On Tue, 2007-05-29 at 13:39 -0600, Paul Martz wrote: FYI: http://www.ddj.com/dept/linux/199702225?cid=RSSfeed_DDJ_All ...something we've been doing for like--6 years. :) *grin* Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Another osgEphemeris compile error
Don Burns set these up (perhaps even just today); I'm sure this is where
you'll find the most help...
http://andesengineering.com/mailman/listinfo/osg-ephemeris
...however, I can tell just from looking that the code isn't valid; it's
attempting to construct a new Matrixf object locally using a pointer,
and there are no methods to support this in the Matrixf class.
On Tue, 2007-05-29 at 23:13 +0200, Pieter du Plooy wrote:
Hi list
I have followed the instructions provided by various people to hack
osgEphemeris, and it worked. I have just compiled openscenegraph
1.9.6, and now am trying to recompile osgEphemeris.
Now I get the following error:
Entering directory
`/tmp3/osgEphemeris/src/osgEphemerisLib/Linux32.Opt'
g++ -I../../..//include -Wall -O2 -c ../StarField.cpp
../StarField.cpp: In member function 'virtual void
UPCB::operator()(osg::Node*, osg::NodeVisitor*)':
../StarField.cpp:135: error: conversion from 'osg::RefMatrix*' to
non-scalar type 'osg::Matrixf' requested
make[1]: *** [StarField.o] Error 1
make[1]: Leaving directory
`/tmp3/osgEphemeris/src/osgEphemerisLib/Linux32.Opt'
make: *** [libosgEphemeris.so.opt] Error 2
Relevant code is :
class UPCB : public osg::NodeCallback
{
public:
UPCB( osg::Uniform *MVi ): _MVi(MVi), a(0.0) {}
virtual void operator()(osg::Node* node, osg::NodeVisitor*
nv)
{
osgUtil::CullVisitor *cv =
dynamic_castosgUtil::CullVisitor *(nv);
if( cv != 0L )
{
osg::Matrixf m = cv-getModelViewMatrix(); (THIS IS
LINE 135!!!)
osg::Matrixf mi;
mi.invert(m);
//a += osg::PI/180.0;
//mi = osg::Matrix::rotate( a, 1, 0, 0 );
mi(3,0) = mi(3,1) = mi(3,2) = 0.0;
_MVi-set( mi );
}
traverse(node,nv);
}
private:
osg::ref_ptrosg::Uniform_MVi;
double a;
};
Any help on this one?
Regards
Pieter
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] 2d library
On Fri, 2007-05-25 at 08:49 +0200, Mario Valle wrote: osgEgipt? I don't know if you meant osgEgypt, but that also works too. :) I've been writing two NodeKits: osgCairo: a lightweight wrapper around Cairo Image surfaces for OSG (Cairo is a vector graphics drawing library; in my opinion, an non-vector kit is useless) osgEgypt: a generic embedded Python image loader, which I've been personally using to test osgCairo. Basically, it embeds the Python interpretter and exposes a single module with a single set_image() function which will let you load a Python script as an OSG texture. :) You can find them here: svn co http://svn.const.lugatgt.org/osgCairo/trunk svn co http://svn.const.lugatgt.org/osgEgypt/trunk You'll have to edit the Makefiles, but that should be very easy (1 or 2 lines) and straightforward. Oliver Schoenborn wrote: Anyone know of an osg-based library that provides 2d stuff like arcs and circles and lines and symbols etc? I have some HUDs to make and it would be nice to not have to create all that from scratch. Thanks, Oliver ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] collada dae plugin on windows
On Thu, 2007-05-24 at 19:53 +0100, Robert Osfield wrote: On 5/24/07, Gerrick Bivins [EMAIL PROTECTED] wrote: Does the collada plugin support animations? Not yet. It'd need to know about osgCal to do this. Well, even before this Cal3D would need to break itself up so that the skeletal components could be used w/out using it's own model format. One of us Cal3D guys just needs to sit down and do it... although, these days, it really would make the most sense to do it this way ANYWAYS, since you're going to end up supplying your own buffers in hardware... Bah, now I'm just rambling. :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSGEdit progress
I've been following this project for a while now and am very excited about it. :) Also--if you're too busy lately with this to have any time to work on the Blender osgexport script, why don't you let me take that over? :) *grin* I might even be able to help with osgedit some, since I have a lot of experience using GTK and a growing amount of experience using OSG. The move to GTKMM is probably a good one, as I personally have a lot of trouble adhering to clean OO programming paradigms when GTK is so heavily based on using callbacks (though it's easy enough to make static shims, it's just a chore...) On Tue, 2007-05-22 at 02:22 +0200, Ruben wrote: Hi osgers, I've been working a bit the last month in the next version of OSGEdit. I'm working on supporting all the OSG nodes and objects and porting the user interface to gtkmm (C++ wrapper of GTK). Right now, I have support for every osg object (only osg namespace at this moment), with almost every attribute editable from OSGEdit. Other namespaces, like osgParticle or osgSim will be added next, with little effort. You can see an screenshot of how the automatic properties page of osg::Texture2D looks like in the project page: http://osgedit.sourceforge.net/ If you are interested in the development progress, I will be posting news and screenshots periodically on this page. The source code will be available through svn for testing as soon as I have a solid codebase. Regards. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] How To Ask A Question
A co-worker and I were reflecting on the difficulties of asking a good question and he introduced me to his inspiration: http://www.catb.org/~esr/faqs/smart-questions.html Just figured I'd post this here, since these are the only lists in which I try to read every post. It's actually a little embarrassing, as many of the major mistakes discussed in that document I've not only made myself but made on these very lists. :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] How To Ask A Question
On Mon, 2007-05-21 at 19:19 +0100, Robert Osfield wrote: Look like a good thing to post on the Support page :-) Wiki password is osg, hint hint :-) Done. :) On 5/21/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: A co-worker and I were reflecting on the difficulties of asking a good question and he introduced me to his inspiration: http://www.catb.org/~esr/faqs/smart-questions.html Just figured I'd post this here, since these are the only lists in which I try to read every post. It's actually a little embarrassing, as many of the major mistakes discussed in that document I've not only made myself but made on these very lists. :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] ortho2D and 1-to-1 pixel/texel mapping
On Thu, 2007-05-17 at 11:27 -0400, Jean-Sébastien Guay wrote: Hello, I'm having trouble setting up a simple scene with an ortho2D projection. I have looked at many examples (osghud, osgpick, osgmovie, ...) and I can't see what I'm doing wrong. It should be simple, but I feel I'm running in circles. Here's basically what I'm doing. First, I create a quad like this: osg::Geometry* polyGeom = osg::createTexturedQuadGeometry( osg::Vec3( 0.0f,0.0f, 0.0f), osg::Vec3(1280.0f,0.0f, 0.0f), osg::Vec3( 0.0f, 1024.0f, 0.0f), 0.0f, 0.0f, (useTextureRectangle ? 1280.0f : 1.0f), (useTextureRectangle ? 1024.0f : 1.0f)); osg::Geode* geode = new osg::Geode(); geode-addDrawable(polyGeom); geode-getOrCreateStateSet()-setMode( GL_LIGHTING, osg::StateAttribute::OFF); It's my understanding that this creates a quad with corners (0,0,0), (1280,0,0), (1280,1024,0) and (0, 1024,0) and where the texcoords match (depending on the use of textureRectangle or texture2D). This geode is given to the viewer. Then, the viewer's projection and view matrices are set like so: viewer.getCamera()-setProjectionMatrixAsOrtho2D(0.0, 1280, 0.0, 1024); viewer.getCamera()-setViewMatrix(osg::Matrix::identity()); viewer.getCamera()-setViewport(0, 0, 1280, 1024); Try adding: camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); camera-setRenderOrder(osg::Camera::POST_RENDER); I don't think your quad is being created incorrectly, I think it has everything to do with how the camera is being setup... The rest of the code is based on the osgviewer application, so right after setting the matrices the viewer is run. return viewer.run(); The problem is that I don't see the quad. If I comment out my setProjectionMatrixAs... line (therefore the viewer sets its projection according to the geode's bbox automatically) then I see the quad, but when it's set to ortho2D it isn't displayed. Also, moving around the scene with the mouse doesn't change anything. My ultimate goal is to display the quad fullscreen with perfect 1-to-1 mapping between screen pixels and texels on the quad. Looking at straight OpenGL tutorials on this, it should work, and after trying lots of things to achieve this in OSG it seems that I am not getting closer at all. Any help would be appreciated. Thanks in advance, ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] new osgCal: preliminary version available
On Tue, 2007-05-08 at 00:03 +0400, Vladimir Shabanov wrote: 2007/5/7, Jan Ciger [EMAIL PROTECTED]: Vladimir Shabanov wrote: * unix tool `sed' for converting *.glsl into shaders/*.h files (It would be good if this step will be configurable, i.e. end users use generated shaders/*.h files, while developers have an option to regenerate them when source .glsl is changed (as it is in current makefile)). I think that an even better option would be to simply load the shaders on the fly from the text file. Why do they need to be hard-compiled into the code? I think that the sed dependency and the associated messy scripting more than outweigh any benefit this could have. I think that external files are more maintenance pain that hard-coded shaders. It's simpler to have one library than the library + 2 shader files with obscure location. Also current two shader files are really many more shader files since conditional compilation is used (look at those #ifdefs). Current approach with using `sed' simplifies creating different shaders depending on material parameters. When using external files I must do conditional compilation by hand (not sure that OpenGL allows to define preprocessor defines). So I think that using generated files plus option to regenerate them for developers would be better solution. I can't say I agree with this at all. If you must, have a directory layout of shaders in an archive of some such and load them from there... you could even build a shader buffer internally based on various criteria during runtime. Integrating sed w/ source, however, and then trying to modularize that code as a useful, reusable library just doesn't fit with my personal opinion of what OSG is now and will hopefully continue to be. Something about it just feels wrong... Then again, I'm a small fish in a big ocean, and my opinion means very little. :) It's great to see activity, at any rate... :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] SIGGRAPH // August, 2007
Does anyone here know for sure they're going this year? Any chance of folks being interested in splitting hotel room costs? :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Creating an image for a texture
On Thu, 2007-05-03 at 20:55 +0100, Robert Osfield wrote:
Hi Rick,
I'm not sure that this will make the difference, but you could try
setting the internal texture format to GL_RGBA, via:
image-setIternalTextureFormat(GL_RGBA);
As there is change that OpenGL doesn't like the GL_BGRA for internal
texture format.
Robert.
I inherit from osg::Image w/out any trouble at all in osgCairo. If you
want to take a look at how I do it, SVN is here. The code base is very
small, maybe 300 lines total?
svn co http://svn.const.lugatgt.org/osgCairo/trunk osgCairo
On 5/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello All,
I am stuck trying to work out how to programmatically create
an image for a texture.
Here is what I have so far:
osg::ref_ptrosg::Image image = new osg::Image();
int s, t; s=t=256;
image-allocateImage(s, t, 1, GL_BGRA, GL_UNSIGNED_BYTE);
for (int row = 0; row t; ++row)
{
for (int col = 0; col s; ++col)
{
unsigned char* newImageData = image-data(col, row);
newImageData[0] = row;
newImageData[1] = col;
newImageData[2] = (row+col)/2;
newImageData[3] = 255 - b;
}
}
// It does not seem to work if I do not write the image out
and read it back in
osgDB::writeImageFile(*image, temp.bmp);
image = osgDB::readImageFile(temp.bmp);
osg::ref_ptrosg::Texture2D texture = new osg::Texture2D;
texture-setImage(image.get());
...
In this code, I am writing the image to a temp file and then
reading it backout again. It seems that if I do not do this,
it does not work. I am guessing I am not creating the image
properly, but the .bmp writer is smart enough to figure it out
whereas the Texture2D does not like it. I tried looking at
the more verbose output and did not see anything different. I
wrote both files out to a .osg file, but they were identical
(neither showing a texture. Where are textures stored when
writing osg files anyway?)
This is actually all in my effort to get the osgDB_lwo reader
using the transparency map from the .lwo file itself. I did
not imagine I would have such a tough time of it :( . Even
by writing the .bmp out and reading it back in, I am not
getting the alpha channel for the blending. I have tried
allocating the image with GL_BGR, with no more success.
Like I said, I am sure I am doing something wrong. someone
please help :O Perhaps there are examples somewhere of
manually creating an image as a texture?
You graveling servant
-- Rick
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Pixel-Picking (HUD) with Alpha
Is there a fast, existing object in OSG that allows picking which ignores pixels that are completely translucent (or perhaps have an alpha value lower than some threshold?) I'm using the osgpick example as my reference, and the LineSegmentIntersector class does indeed have a number of interesting features. However, I didn't see any convenience methods for getting the color of the currently active coord. In fact, that might be totally outside the scope of the Intersector in the first place. I tried searching the archives, but perhaps I'm not using the right search terms. I'm almost certain something like this is a solved issue with a very good answer, but so far I'm not able to find anything. (I had the idea of using Fragment Shader, but it really seems like overkill. My suspicion is that the answer will involve taking the coordinate values from the intersector, grabbing the closest pixel from the buffer using those coords, and testing that--I'm just not sure how easy/fast it is to do that...) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Linux x86 vs. x86_64
On Wed, 2007-04-25 at 23:02 +0200, Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donald Tidrow wrote: Which version is faster for most uses? I'm going to be installing a new version of Linux on my home machine, now that I've updated the hardware, but haven't decided whether to run an x86_64 version or the i586/i686 one. Has anyone done any comparisons between them, especially with regards to running OSG? We have done some tests running Blender and in fact the 64bit version didn't have much of an advantage in performance. If you are not going to use a lot of calculations with large numbers or need a lot of RAM, the 64bit system will not bring you a whole lot of benefit, only problems with some 32bit-only applications people like to have (e.g. Flash plugin is 32bit only, Acrobat is 32bit only, etc.) Applications need to be specifically optimized for 64bit code to really feel the benefit, not only recompiled by 64bit gcc. You can see for yourself here: http://www.eofw.org/bench/ Comparable hardware scores very similarly, whether it is running 32 or 64bit Linux system. Also, regarding OSG the 64bit system doesn't seem to have much benefit (or bad impact for the matter). It behaves pretty much the same as my 32bit machine and the performance is comparable. Having access to hundreds of new, modern top of the line laptops, I can also confirm this. We see little-to-no perceivable speed increase with 64bit systems+OSes, other than in applications like octave (MATLAB) or various encoding apps that are compiled to benefit from 64bit. As a matter of fact, we insist that any customer who wants 64bit ALSO dual-install the 32bit equivalent, just in case things go (and they often do) awry. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGL8Hon11XseNj94gRAhE0AJ0Zx1YVWlNUNNgyspeaLFaJ8tZZJACfd3rX VaOfHjiTL23tAVXzXDm2490= =enXy -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] cal3d lod
On Wed, 2007-04-25 at 05:10 +0400, Vladimir Shabanov wrote: 2007/4/24, Jan Ciger [EMAIL PROTECTED]: Could be. However Ruben tends to reply, give a few days. He is also reading this list (Loïc probably too). I've received a Ruben's reply. He added me to osgCal developers list. After some cleanup I will publish the code and (possibly) some test models. I think it will happen somewhere in the next week. Me too! This IS good news. :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] cal3d lod
On Sat, 2007-04-21 at 22:51 +0400, Vladimir Shabanov wrote: 2007/4/21, Jan Ciger [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Vladimir, Vladimir Shabanov wrote: Hello Jan! I've also developed a library based on LGPL osgCal (actually a nearly complete rewrite) which works with latest OpenSceneGraph, uses GLSL shaders for skinning and support normal mapping. Fixed function implementation is also kept. Library have some optimizations especially for hi-poly models. OSG picking is also works for HW models. Library is tested on ATInVidia on linuxwindows. LOD .osg file plugin is not supported. I've also done some small changes in cal3d Max exporter, to export normal maps, bumps opacity. Excellent - that will probably save a lot of work for many people. Would you be willing to attach that code here? (Or provide it somewhere downloadable?) I have SVN access to Cal3D, so I can put the nodekit on GNA.org and provide a link to it (and others) on the website. It is one of purpouses to release it. There are much work done and a much work to do. People should not reinvent the wheel. In the (possibly near) future, I want to release this library as a major update to LGPL osgCal. Great! That's a really commendable attitude. A week ago I've tried to contact Loïc Dachary (as osgCal project manager at sourceforge), but received no answer. It seems that now I should contact Ruben? Am I right? Well, Loic maintains the GPL nodekit w/ Underware, not the LGPL one (although he is the main person in the Cal3D project itself). Yes, I think so. Loïc maintains the forked (GPL) version of osgCal and not the original LGPL one (which is, curiously, named osgCal2). For that you need to contact Ruben Lopez who is maintaining it. He is also on the osg-users mailing list. OK, I've just mailed Ruben. Regards, Jan ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Development release OpenSceneGraph-1.9 made
On Mon, 2007-04-23 at 11:01 +0100, Robert Osfield wrote: Hi All, I have now begun the regular tagging and release of the development version (SVN) of OpenSceneGraph, the first product of this effort is OpenSceneGraph-1.9. I am placing all the developer releases under SVN, to make it easy to keep track up them: Hey Robert, do you keep a ROADMAP or TODO file or anything like that? I think it would be interesting to know what kinds of things you (and perhaps others) are working on at the moment... To find the developer releases simple browse: http://www.openscenegraph.com/svn/osg/OpenSceneGraph/developer_releases/ The specific location of the OpenSceneGraph-1.9 release is: http://www.openscenegraph.com/svn/osg/OpenSceneGraph/developer_releases/OpenSceneGraph-1.9/ In this folder you'll find : OpenSceneGraph-1.9.zip RELEASE_NOTES.txt I have also tagging and built equivalent OpenThreads developer release too: http://www.openscenegraph.com/svn/osg/OpenThreads/developer_releases/OpenThreads-1.9.3/ The version number 1.9.3 should really be 1.9 but my release scripts were quite perfected, so took several goes before everything was automated and working correctly If users want to build binaries for these developer releases then please just send them to me, or if you are regular contributor of binaries we can get you write access on the developer_releases directories and you can upload them directly. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Development release OpenSceneGraph-1.9 made
On Mon, 2007-04-23 at 12:12 -0500, Mike Wittman wrote: Hi Robert, I'm glad to see these intermediate development releases. For those of us that aren't able to keep up with SVN on a daily basis it makes a lot of sense to have well-known reference points at a coarser time granularity to work against. By the way, I just downloaded and unpacked the 1.9 release and noticed a couple issues with the packaging: - the OpenSceneGraph-1.9 package appears to have a second duplicate instance of the source tree in the trunk subdirectory - both the OpenSceneGraph and OpenThreads packages still contain .svn directories and all the files they contain In your scripts Robert, you could use svn export to first create a .svn-dir-free tree, then make the packages from that. In fact, svn export is pretty much my favorite command ever. I'm assuming both of these were unintentional; they certainly increase the size of the packages substantially. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, April 23, 2007 5:01 AM To: osg users Subject: [osg-users] Development release OpenSceneGraph-1.9 made Hi All, I have now begun the regular tagging and release of the development version (SVN) of OpenSceneGraph, the first product of this effort is OpenSceneGraph-1.9. I am placing all the developer releases under SVN, to make it easy to keep track up them: To find the developer releases simple browse: http://www.openscenegraph.com/svn/osg/OpenSceneGraph/developer_releases/ The specific location of the OpenSceneGraph-1.9 release is: http://www.openscenegraph.com/svn/osg/OpenSceneGraph/developer_releases/ Op enSceneGraph-1.9/ In this folder you'll find : OpenSceneGraph-1.9.zip RELEASE_NOTES.txt I have also tagging and built equivalent OpenThreads developer release too: http://www.openscenegraph.com/svn/osg/OpenThreads/developer_releases/Ope nT hreads-1.9.3/ The version number 1.9.3 should really be 1.9 but my release scripts were quite perfected, so took several goes before everything was automated and working correctly If users want to build binaries for these developer releases then please just send them to me, or if you are regular contributor of binaries we can get you write access on the developer_releases directories and you can upload them directly. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ Mike Wittman [EMAIL PROTECTED] ___ Seismic Micro-Technology, Inc. 8584 Katy Freeway, Suite 400 / Houston, Texas 77024 Tel. +1 (713) 464-6188 Fax. +1 (713) 464-6440 Web: www.seismicmicro.com ___ Seismic through Simulation with KINGDOM, (RC)2, and SURE! - CONTACT US TODAY for more information. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Grome, level and landscape modeler, integrates with OSG
On Sun, 2007-04-22 at 23:52 -0700, LiCU A wrote: Hello everybody, Quad Software announces the availability of its level and landscape editor, Grome, which integrates out-of-the-box with OSG rendering engine. Grome is a versatile editor geared towards professional games and 3D simulations developers. Using a hybrid approach, the editor allows for fast procedural landscape creation using fractal and erosion algorithms and also for complete control by using multiple layers of heightmaps, selections and textures together with a highly customizable brush system. Its included SDK comes with OSG exporter with source code demonstrating the full terrain rendering inside OSG engine using multitexture and multipass techniques. For demo version, video tutorials and more information visit the product home page: http://www.quadsoftware.com/index.php?m=sectionsec=productsubsec=editor Has anyone here tried this before? This looks really, really freaking cool. :) Is there a Linux client? We are also planning to make a tutorial with details of Grome integration with OSG and make it available to the public in the next period. For more details don't hesitate to contact us at [EMAIL PROTECTED] Regards, Adrian Licu Software Engineer Quad Software www.quadsoftware.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgEgypt (Just a toy!)
I've been playing around with something I had an idea for a few days back which allows me to load python scripts as images in OSG. :) Basically, it consists of two parts: the library (libosgEgypt) and the plugin for file loading (osgdb_egypt). The way it works is each .egypt file is actually a python script that is parsed by the embedded interpreter and expects a call to the module function osgEgypt.SetBuffer(). Right now there isn't any customization available, but it does work. What this means is that using osgEgypt, OSG can load any image format Python can. An example .egypt file looks like the following: -- import osgEgypt ...do fancy image stuff (I like using Cairo, personally)... osgEgypt.SetBuffer(myName, buffer(imgdata), 128, 128) -- Then, you could use osgviewer to check out the results: # osgviewer --image file.egypt ...although it doesn't setup alpha properly using osgviewer, so I wrote a small example application (osgegyptviewer) to do just that. Anyway, I just wanted to share this fun toy with anyone who might be interested. You'll need basic Makefile skills to get it to build, since I just kinda' put this together impromptu, but the code should be clean and easy to follow. svn co http://svn.const.lugatgt.org/osgEgypt/trunk osgEgypt (Eventually, osgEgypt would like to become a full gadgets API like CEGui, except that it uses Python instead of LUA and integrates cleanly with OSG. Furthermore, I'd really like to encourage the use of Cairo with this kind of stuff. In fact, the example image I include is a cairo-based one!) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] cal3d lod
On Thu, 2007-04-19 at 22:54 +0200, Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Luigi Calori wrote: Our requirements: 1) it should work with latest SVN Both Replicant and osgCal should be able to. Replicant does (at least my fixed version), osgCal should work or at least should be trivially fixable (somebody mentioned some compilation issue recently). I didn't try to compile it myself recently, though. I did! drawImplementation doesn't take a StateSet anymore; it seems like that has been switched to a RenderInfo reference instead. 2)it should work under windows Both osgCal and Replicant do. Nice things to have 3)Tutorial (ease of use) and some viable path to export content from MAX (or Blender) Cal3D has some tutorials on the web site how to model and export from MAX. If you need Blender, look for Soya3D engine, they have a decent I always consider and integrate the changes I see Jiba make to SVN proper. They're currently no different, unless Soya3D has been sneaky, sneaky on me in the last 2 months. exporter in their SVN. Cal3D characters work with both osgCal and Replicant, but for Replicant you will need to write an .rbody file defining the higher level actions. Whether the export is viable that depends on what you need. If you need few simple guys without high-end features, it will do. 4)it should support not only humans but also different skeletons Cal3D supports arbitrary skeletons (e.g. an octopus). 5)hardware skinning Tough luck so far, unless: a) you write it yourself b) use the GPL version of osgCal which is supposed to have it (I didn't try it myself). c) osgCharacter does have it, however it is more an experiment than a usable toolkit. 6)nodekit / plugin wrapping, so to being a ble to treat animated characters as other osg /ive files Replicant has that, however it is not that simple - one guy can have many animations + other data files. The osg/ive file will contain only the geometry and textures, not the skeleton and the animations. It doesn't even make much sense because these are not scene graph related in any way. The osg/ive file is not designed to be a replacement for a zip archive/folder/CD with all the assets needed by your application. On the other hand, the osgCal characters and Replicants are regular nodes in the scene graph, so from this point of view your work with them in the same way as with any other geometry. 7)some form of LOD support (when a character is far awy shoul consume less draw / update time) The underlying Cal3D library has that, however see the discussion on LODs before. From a user perspective, it would be really nice to see developer join force on one common projects instead seeing multiple efforts. Yeah, but there aren't *that* many developers interested in developing this. Are you volunteering? I think it would be neat to see Collada squash the whole thing, but that's just me. :) A universal language for expressing character animations would rock. Implementations would still have the freedom to optimize as they see fit, but at least interchangeability and whatnot would be out of the way... Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGJ9btn11XseNj94gRAhwoAJ44WFa6CBkjrU5sPOy0MA7J13OeAgCeP6tq dho5Rvullf7+HtxlJt1v5N4= =t/Mk -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] cal3d lod
Palle Raabjerg and I rewrote most of the Cal3D exporter for Blender (he as a Google SOC project and myself just out of curiosity) that is currently in Cal3D SVN (I also put up the new funky website!). I didn't write any of the LOD code however, and I can confirm it is certainly not in a working state at the moment; I do plan on revisiting it eventually. There isn't a lot of activity lately unfortunately, but I don't believe the project is dead... On Tue, 2007-04-17 at 17:05 -0400, Zach Deedler wrote: I spoke too soon. I am able to replace a submesh and have the animations still work. Just had to modify the model properly in 3d studio max. Looks like I'll just have to modify rbody to paste all the meshes/submeshes together with LODs. I'm pretty sure this should be possible. Zach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jan Ciger Sent: Tuesday, April 17, 2007 16:45 To: osg users Subject: Re: [osg-users] cal3d lod -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zach Deedler wrote: Jan, So you have this setup?: lod-man1.hi-res \-man1.med-res \-man1.low-res How did you manage the animations between the LOD's? For instance, switching from the low-res to the high-res, won't the walking animation restart, or be in a different position? I didn't have that issue because we were driving the skeleton externally and used Cal3D only for skinning. So the skeletons were forced into the same position from a common external skeleton driven by our in-house animation library. That is not the most common use case, I admit. However, I believe that the synchronization could be done, but you will have manually set the position within the current animation when you switch the LOD. An on-update callback could do that. I think we discussed this before, but I thought you replaced all the different submeshes with LODs; not the whole model. No, the whole model. It will not work with submeshes - if you replace a submesh, let's say for the torso, you will have to completely change the skinning parameters to adapt to the new topology of the mesh (different number of vertices). Perhaps that is possible too, but I am not aware of an API to do so easily. The system of adding and removing submeshes seems to be intended more for attaching e.g. armor or weapons/tools to the guys, not for implementing LOD levels. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGJTG9n11XseNj94gRAjWXAJ0bydUoqWVPiXnoOpNRDYd+/nusBgCfTS/7 /soMZSSAeELwuCPHHhVjJT0= =iCUR -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] cal3d lod
On Wed, 2007-04-18 at 16:57 -0400, Zach Deedler wrote: Hi Jan, Do you know where the most current version of osgCal is? The LGPL version. I swear there is a conspiracy to shut all this stuff down by some major animation company or something? All this stuff is just not being supported. Hmmm. Okay. Er. :) There are 2.5 versions: 1) The one by Loic Dachary and friends at Underware. This is GPL, but supports HW skinning from what I can tell (using Cal3D's HardwareModel class) This is generally just called osgCal. 2) The LGPL one by Ruben Lopez (with some fixes by Jan Ciger). On it's website, this is called osgCal2, but it's almost certainly what people are referring to when they say osgCal. From your post, it seems like this is the one you want. https://sourceforge.net/project/showfiles.php?group_id=79240 2.5) Is my personal adaptation (which I am deriving from osgCal2) which has code cleanup, supports OSG SVN, and will include Vertex Shader animation support. I absolutely cannot suffer software skinning after seeing how much faster it is in a simple shader. :) I haven't actually released mine yet (though obviously the LGPL will require I do so) as it is still in casual development, but it will be available along with all the other OSG stuff I'm working on (osgGTK, osgCairo, osgEgypt, etc.) None of these are really all that impressive at the moment, but hopefully will be soon. :) Zach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jan Ciger Sent: Wednesday, April 18, 2007 16:31 To: osg users Subject: Re: [osg-users] cal3d lod -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zach Deedler wrote: Ahhh crap. I was afraid of something like that. I wish I would've went with cal3d in the first place myself. gr I actually chose it because I saw that Delta3D was using it, so it must have some benefit. Since I don't use any of the contact translation, though I don't think I get much benefit, except the creation of the osg geometry. I have had problems LODing, switchable objects, and access to animation speed. I've resorted to hacking away at ReplicantBody, though. Are you saying that these calls are pushing the vertices onto the GPU? cal_renderer-getVertices((float *) m_geometry-getVertexArray()-getDataPointer()); cal_renderer-getNormals((float *) m_geometry-getNormalArray()-getDataPointer()); Any OSG experts know how I can get the cal3d vertex arrays jammed into OSG efficiently? What about using osgCal ? That does everything that you may want :D Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGJn/3n11XseNj94gRAioJAJ9wv3E0q8BVXHgTxMRSpazIwIQmRACePLUz atoni9LWKe2JhSFJHhNfhmg= =t+J7 -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Graphical gadgets
On Wed, 2007-04-18 at 21:31 +0200, Ivan Bolčina wrote: For graphics (HUDs) I render directly to textures. I had idea of using Cairo, but haven't got time to investigate it. I'm doing this exact thing with a nodekit I'm experimenting with called, aptly, osgCairo. :) I'm also building a widget library on top of that called osgEgypt. However, right now it's pretty rudimentary. I can, however, provide the svn URL to anyone who's bored enough to want to see. 2007/4/18, Anders Backman [EMAIL PROTECTED]: Nothing that I know about. Marco was working on osgWidgets for quite some time ago, but I guess it has stalled? Marco? Other than that I could recommend CEGui, which is rendered using OpenGL. We are using it together with a custom drawable that renders the CEGUI widgets. It has sliders buttons, lua scripting, etc... /Anders On 4/18/07, Mustafa [EMAIL PROTECTED] wrote: Hi all, Is there any toolkit to add buttons, sliders, textboxes on the HUD etc. for interaction? Sure these gadgets are based on OSG classes not MFC, QT etc. I want to add interaction functionality which can be shown/hide like HUD in a platform independent manner and they will trigger special callbacks like button click, text changed etc. Best, ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Full screen anti aliasing on NVIDIA hardware?
On Mon, 2007-04-16 at 17:12 +0100, Robert Osfield wrote:
Hi Marc,
FSAA certainly works on OpenGL and NVidia just fine. Have a browse
through the OpenGL driver settings and you should fine it.
Robert.
On 4/16/07, Marc Bernatchez [EMAIL PROTECTED] wrote:
Hi all,
I have been trying to force FSAA through the NVIDIA drivers for a while
but apparently, it only anti alias Direct3D applications but not OpenGL
ones. Does any of you who use NVIDIA hardware can give me some tips on
how to force FSAA on OSG OGL applications?
If you're using Linux of FreeBSD, the following will work:
# __GL_FSAA_MODE=${MODE} osgviewer foobar.osg
...where MODE is a number 0-8 which, generally, means increase quality
w/ value (though, I think 3 is disable, same as 0). On Windows, er...
I have no idea.
Thanks
--
=
Marc Bernatchez
Candidat au Ph.D.
Ecole Polytechnique de Montreal
Montreal, QC, CANADA
=
Virtual Reality web site, VResources:
http://vresources.org
=
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Suitable laptop
On Thu, 2007-04-12 at 16:03 +0100, Alan Harris wrote: Hi Has anyone got a recommendation of a laptop (UK availability and not a 4kg monster) that would be good for driving an osg derived program - I assume it would need an nVidia card from comments I have seen. Is there any known problems with Vista (at any particular level) - there have been some messages but some people seem to have no problem. Thanks for any help Am I allowed to respond to this? *grin* (Note the domain name! I don't want to get booted from the lists by advertising, though. Still, he asked! :)) Give one of our sales guys a call if you're interested. Of course, we install Linux on all of these machines, but I'm using a DualCore M90 with XP/FC6 and a Quadro 2500M and have no trouble pushing anything graphical, OSG or otherwise. Our experience with Vista, however, has been so-so; not that we're Windows experts or anything. Alan Harris ___ osg-users mailing list [EMAIL PROTECTED] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list [EMAIL PROTECTED] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OpenSceneGraph with CMake on FreeBSD
On Tue, 2007-04-10 at 20:03 +0100, Robert Osfield wrote: Hi Martin, Do you manually install OpenThreads to /opt/OSG/lib and include? Is there a reason for it not being in /opt/lib or /usr/local/lib? I'm not familiar with FreeBSD but cmake should be able to find OpenThreads if installed in standard places, i..e by doing a make install in OpenThreads. With custom install locations you can specify the directory via OPENTHREADS_DIR which will allow cmake to pick up both the the include and lib directory relative to this directory. The OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY vars themselves are part of the CMake build system rather than env vars, so you can set this using ccmake rather than cmake. Robert. I install OSG to ~/local, got this same error, and was able to easily resolve it using ccmake . and changing those two variables accordingly. On 4/10/07, Martin Spott [EMAIL PROTECTED] wrote: Now that people are forced to use CMake in order to stay current with OSG I have a little question concerning CMake. I'm using the copy of a pristine SVN update and I'm referring to: http://www.openscenegraph.com/osgwiki/pmwiki.php/Build/CMake quickstep: 18:36:49 /usr/local/src/OpenSceneGraph ccmake --version quickstep: 18:36:54 /usr/local/src/OpenSceneGraph env OPENTHREADS_INCLUDE_DIR=/opt/OSG/include OPENTHREADS_LIBRARY=/opt/OSG/lib ccmake . I guess I have to press c to configure. Afterwards: CMake Error: This project requires some variables to be set, and cmake can not find them. Please set the following variables: OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY This doesn't make much sense to me. Anyone having a clue here, any recommendations on where to start searching for the reason of such misbehaviour ? BTW, I guess cmake is the batch-mode complement to ccmake - right ? Unfortunately the 'result' is the same. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OpenSceneGraph with CMake on FreeBSD
On Tue, 2007-04-10 at 21:12 +0100, Robert Osfield wrote:
Hi Jermy,
On 4/10/07, Jeremy L. Moles [EMAIL PROTECTED] wrote:
I install OSG to ~/local, got this same error, and was able to easily
resolve it using ccmake . and changing those two variables
accordingly.
~/local isn't a standard path for installing things so the
OpenSceneGraph/CMakeModules/FindOpenThreads.cmake won't find it - any
time you install something in a non standard place automated scripts
won't be able to find them, so you'll have to set the vars via ccmake
.
Oh, I know--I always have to do some foolery for my $HOME/local stuff.
Personally, I think everyone should be using this paradigm, but that's
just me. :) The point is, CMake is robust enough to allow whatever you
want and facilitates the adjustment of these knobs in a very acceptable
way.
The paths that FindOpenThreads.cmake currently searches is:
FIND_PATH(OPENTHREADS_INCLUDE_DIR OpenThreads/Thread
${CMAKE_INSTALL_PREFIX}/include
$ENV{OPENTHREADS_DIR}/include
$ENV{OSG_DIR}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include
/usr/include
/sw/include # Fink
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
)
FIND_LIBRARY(OPENTHREADS_LIBRARY
NAMES OpenThreads OpenThreadsWin32
PATHS
${CMAKE_INSTALL_PREFIX}/lib
$ENV{OPENTHREADS_DIR}/lib
$ENV{OSG_DIR}/lib
~/Library/Frameworks
/Library/Frameworks
/usr/local/lib64
/usr/local/lib
/usr/lib64
/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
)
FIND_LIBRARY(OPENTHREADS_LIBRARY_DEBUG
NAMES OpenThreadsd OpenThreadsWin32d
PATHS
${CMAKE_INSTALL_PREFIX}/lib
$ENV{OPENTHREADS_DIR}/lib
$ENV{OSG_DIR}/lib
~/Library/Frameworks
/Library/Frameworks
/usr/local/lib64
/usr/local/lib
/usr/lib64
/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
)
As you'll see from the above lists /usr/local, /local and /opt should
all be checked.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
RE: [osg-users] cal3d LODs
On Thu, 2007-03-15 at 16:23 -0400, Zach Deedler wrote: Hi Jeremy, Yeah, I'm trying to figure out how to create discrete levels of detail, within the file, and have it animate fluently in the transition. Doesn't the cal3d_miniviewer use OpenGL, though, and not OpenSceneGraph? Well, there are at least two easy-to-use Cal3D OSG NodeKits--one by the guys at Underware (which is GPL) and the other (original) which is LGPL. I'm also working on my own Cal3D NodeKit to do the animation in a vertex shader (which gives me about 500% performance improvement), which I'll hopefully have done soon. The NodeKit may provide some easy wasy to set the LOD level, but if not--it's a simple method call to setLodLevel(). We use the 3DS Max exporter, but I don't believe it allows for LODs. Ack--I wasn't aware of that. :( Zach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy L. Moles Sent: Thursday, March 15, 2007 15:40 To: osg users Subject: Re: [osg-users] cal3d LODs On Thu, 2007-03-15 at 15:27 -0400, Zach Deedler wrote: Hello osg-animators, Sorry about all the emails recently. I'm just trying to finish up a project. Thanks for all the help. It has saved me some time, and thus gained me some sleep. I know this isn't the place to discuss cal3d, but this place has the smartest people, and maybe some people have some experience with cal3d here. Has anyone played around with creating LODs for Cal3d or ReplicantBody models? We have some nice cal3d models, but they have too much geometry. Palle Raabjerg and I recently attempted to rewrite the Blender exporter--and I know he had a whack at creating a better LOD algorithm--but I'm not sure he had enough time to make it really functional. If you're using one of the other exporters however, it may work a lot better. :) The model format itself supports LOD (fire up the cal3d_miniviewer and use the 1-9 keys), it's just a matter of exporting it correctly. Thanks. Zach ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] VBO's in Drawable::drawImplemention
I have a situation where I'd like to use VBO's in my custom drawable's drawImplemention method. I have experience using VBO's in a normal sense by making calls to OpenGL directly, but I'm _certain_ OSG provides a more sensible, safe way to do this. I've investigated the BufferObject header some, but this doesn't appear to be the place to do it (unless we're supposed to use BufferObject::Extensions directly). The Drawable parent class itself appears to have some internal support for enabling VBO's, but no apparent way to initially populate or bind the VBO's data using BindBuffer/BufferData. Is there something very obvious that I'm missing? Or should I go ahead and implement my Drawable such that it maintains these buffers itself? Better yet, is there some documentation on this issue, or perhaps is this something that might go into Martz's book? :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Performance teaser... ;-)
On Thu, 2007-02-01 at 11:41 -0800, [EMAIL PROTECTED] wrote: On Thu, 2007-02-01 at 16:54 +, Robert Osfield wrote: All OSG objects have a DataVariance variable that you can set and query. If data changes per frame than the DataVariance is set to DYNAMIC, if it doesn't change then its set to STATIC. Oh okay, I thought for a second that you were using the const keyword somehow... which led to my question. MUTABLE! Thanks, Mark ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Embedding YouTube videos in wiki
On Thu, 2007-02-01 at 21:09 +, Robert Osfield wrote: Hi Farshid, On 2/1/07, Farshid Lashkari [EMAIL PROTECTED] wrote: Would it be possible to embed youtube videos on the OSG wiki? I have some videos of OSG based demos that I would like to share with the community, and it would be cool to embed the video directly in the website. I already searched the PmWiki website and they describe how to enable embedding youtube videos here: http://www.pmichaud.com/wiki/Cookbook/Flash I'm no wiki expert so can't comment on how easy it'd be to do. What I can say is we are about to move openscenegraph.org to a new server with new administrators so waiting a week or so might be good before pushing the wiki in new directions. What about moving to Subversion? Is that going to be soon after the new server!? Oh happy day... *grin* Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] NVPerfKit and GLExpert
This may have been brought up before but I was just curious--I know there are mostly only serious developers here, so I figured this was the best place to ask. :) NVidia has had their NVPerfKit package available on Linux for a few months now and last night I had an opportunity to test it out a bit. Has anyone else done any work on abstracting their NVAPI*() stuff into a more general library? Or even better, something that integrates cleanly with OSG? It looked very promising at first glance; the GLExpert stuff couldn't be easier to use, but it really doesn't have a lot of granularity or even useful data, to be honest. The PerfHUD looked great, but required a lot of integration w/ the app in question. Anyways, just curious... ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osg::notify w/ Namespaces
Heyas Robert... I'm working on a few assorted OSG projects (as always) and came across something that inspired me to ask this question: Would it be conceivable to, perhaps, sometime in the future (OSG 2.0?), change the way osg::notify() works so that it always appends SOME kind of contextual prefix to anything it prints out? I thought about this because when your NOTIFY_LEVEL is set to INFO, there is _tons_ of output, and it can become impossible to tell who said what and why, unless the author explicitly says something in the output that keys you off as to it's origin. It also makes it difficult to get just the data you want without the rest... For example, in the osgCal rework I'm doing (not Underware's, as it's GPL, but I'm cleaning up the LGPL one), I'm adding the following prefix to everything I print: osgCal::CoreModel::loadSkeleton: ...some text... Conceptually, of course, I don't think anyone would mind contextual osg::notify() prefixes (would they?), but the implementation would certainly be trickier and possibly non-backwards-compatible. notify() could become a method of osg::Object, which has direct access to the _name member and could use that as a prefix (plus, aren't most things that call osg::notify() already at least osg::Objects?). Or, osg::notify() could take an optional second argument that defined some kind of namespace with a sensible default. Have you had any thoughts on osg::notify() and making the output more uniform/easily-parseable? Is it fine just the way it is? :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Shading on a textured geometry
On Tue, 2007-01-30 at 13:04 -0700, Paul Martz wrote: Hi Sascha -- It sounds like you're using REPLACE instead of MODULATE. See the TexEnv header. Can I make a suggestion? I get the impression you are new to 3D graphics. I'd suggest you purchase the OpenGL Programming Guide (the red book) and learn about OpenGL and 3D graphics in general. It will really help you with a lot of the issues I've seen you post about. This might make your OSG experience a little easier to digest. And then, after reading that, read Paul's work-in-progress OSG book, because it already has some good data! (Then buy it when you can...) :) Hope that helps, -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sascha Kuhn Sent: Tuesday, January 30, 2007 12:28 PM To: osg users Subject: [osg-users] Shading on a textured geometry Hi, I have created a picture from a color array and textured it on a geometry. After including the texture on the geometry the shading of the geometry get lost. Can I set the shading even if a texture is on a geometry. Thanks Sascha ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osg::notify w/ Namespaces
On Tue, 2007-01-30 at 22:25 +, Robert Osfield wrote: Hi Jeremy, The way to do this is to write a local macro i.e. #define osgCal_NOTIFY osg::notify(osg::NOTICE)Party till you drop: osgCal_NOTIFYMessagestd::endl; Well, I knew about NOTICE, but the reason I want on and on about INFO is because it's the default. :) I guess I can implicitly infer you think it's a bad idea then? :) On 1/30/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: Heyas Robert... I'm working on a few assorted OSG projects (as always) and came across something that inspired me to ask this question: Would it be conceivable to, perhaps, sometime in the future (OSG 2.0?), change the way osg::notify() works so that it always appends SOME kind of contextual prefix to anything it prints out? I thought about this because when your NOTIFY_LEVEL is set to INFO, there is _tons_ of output, and it can become impossible to tell who said what and why, unless the author explicitly says something in the output that keys you off as to it's origin. It also makes it difficult to get just the data you want without the rest... For example, in the osgCal rework I'm doing (not Underware's, as it's GPL, but I'm cleaning up the LGPL one), I'm adding the following prefix to everything I print: osgCal::CoreModel::loadSkeleton: ...some text... Conceptually, of course, I don't think anyone would mind contextual osg::notify() prefixes (would they?), but the implementation would certainly be trickier and possibly non-backwards-compatible. notify() could become a method of osg::Object, which has direct access to the _name member and could use that as a prefix (plus, aren't most things that call osg::notify() already at least osg::Objects?). Or, osg::notify() could take an optional second argument that defined some kind of namespace with a sensible default. Have you had any thoughts on osg::notify() and making the output more uniform/easily-parseable? Is it fine just the way it is? :) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] reload the viewer
On Tue, 2007-01-30 at 23:32 +0100, elekis wrote:
hi, for a project, I use the default osgProducer like that:
viewer.setUpViewer(osgProducer::Viewer::STANDARD_SETTINGS);
viewer.setSceneData( root );
viewer.realize();
while( !viewer.done() )
{
viewer.sync();
viewer.update();
viewer.frame();
}
it's very perfect for what I need except for one thing. when I move
some object they can go out of the vision of the camera.
is it possible to recalculate the entiere box of the all the scene and
say that to viewer ?? or for that it's a obligation to have a camera
with a config, etc..Etc...
If you're really using the Producer viewer AND haven't changed any of
the event handling stuff (and you appear to be calling setUpViewer), I
think all you would need to do is press the SpaceBar. :)
thanks a+++
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] osgViewer::Viewer VS osgViewer::SimpleViewer
On Thu, 2007-01-25 at 09:15 +, Robert Osfield wrote: Hi Jeremy, As always, thanks for the great and thorough response. :) As you've found out SimpleViewer is just that its simple, the single Camera associated without doesn't manage a GraphicsWindow like osgViewer::Viewer and CompositeViewer do, it simply implements all the rendering it needs via the local renderingTraversals() method. Right now the osgViewer::StatsHandler creates its own local osg::Camera to do the stats HUD, and assigns the first available GraphicsWindow that the viewer has to the Camera, and then tells the viewer to updating its rendering support (in effect passing GraphicsOperations that wrap SceneView to the GraphisWindow to be rendered each frame). StatsHandler doesn't work with CompositeViewer yet, but potentially it could as its local osg::Camera could reuse the the viewers GraphicsWindow in the same way as the Viewer class. CompositeViewer doesn't yet collect stats though so this is another little bit of work to do. StatsHandlers obviously doesn't work with SimpleViewer either, and here there isn't a GraphicsWindow to assign to its local Camera and SimpleViewer itself doesn't collect any stats... So these are two areas that would need to be coded to add stats support. What would be less coding would be to implement a GraphicsWindowGTK with enough functionality that you could assign such a window to a osgViewer::Viewer are then stats and everything else will work straight off. I looked into this a bit after reading your response. Where does an osgViewer::Viewer object actually figure out what kind of GraphicsWindow* it needs? Is this something determined at compile-time? SimpleViewer is not really intended to be an all single all dancing viewer, its role is to make it quick to integrate with applications that already have graphics windows setup and need to embed OSG into it. But it's so easy to use! :) osgViewer::Viewer and osgViewer::Composite can work with 3rd party windowing libraries, but it requires a little more work, but the rewards are greater for this work. Robert. On 1/24/07, Jeremy L. Moles [EMAIL PROTECTED] wrote: I'm cleaning up the osgsimpleviewerGTK demo (for resubmission) and I wanted to add the ability to toggle the stats display on/off. However, I realized the SimpleViewer object has no way of doing this, which led to a question: I've read the comments in the files, but I can't see the conceptual difference between the two. I can almost use them interchangeably, although osgViewer::Viewer doesn't actually display anything using the code that works for SimpleViewer. It would appear that the SimpleViewer class is much lower level than just the Viewer class, as it makes no attempt to create a window--only a context. At any rate--it should be very straightforward to add stats to SimpleViewer, right? How much interaction will it need (if any?) with the external windowing system--in my case, GTK? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] osgVideo
(INCOMING SHAMELESS PLUG) ...and if you're using Linux, help us test: http://www.neopsis.com/projects/yukon Wee! :) On Wed, 2007-01-24 at 01:29 -0600, Weber, Cory C. wrote: Fraps is hands down the best 3D capture software I have seen to date ... http://www.fraps.com/ although its not free its byfar the best works with OpenGL and DirectX. although its limited by cpu and video card so i don't know if it would work that well on a slow system -CW From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Wed 1/24/2007 1:23 AM To: osg users Subject: Re: [osg-users] osgVideo Here comes another question; Rendering in some systems due to the cpu rate or something else may not be as fast as possible, that is they may not show the graphics in real-time; are these screen capturing software programs able to handle this, may be by writing the color buffer first rather than taking the actual screen image? Hope still some people following this thread :)) Any ideas are appreciated.. Thanks in advance :) On 11/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Using the route described above, you can grab an image from a frame in a post-draw callback and write it to a file regardless of its size and aspect ratio I think, since it is not used as a texture. Any video editing tool (not just AVID) should be able to grab a sequence of frames and make an AVI out of it. I am sure even Window's Movie Maker, the free one that comes with XP will do that. I also ran across a little snippet of code somewhere that you could use to write out an AVI, and even asks for what compression you want using the CODECs installed. I might be able to dig it up if you are interested. The part about running with a constant framerate is critical too, because it takes quite a bit of processor/disk to do it all and the animation will not be smooth. -- Rick On 11/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: When we're putting together promo videos, we just dump out each frame as a tga then use Avid to edit the sequence and turn it into a useable video. Admittedly we have a high-end Avid suite for this, but the dumping of the frames goes from the PS3, down the network and onto our PCs. We run at about 1 fps, but you can capture quite a lot of video by letting it run overnight. In our case, we have several machines capturing different parts of the game, then let the video guys sift through it all. There's no reason why you couldn't set up a 512x512 render target at the top of your scenegraph, change the aspect ratio to that of 720x480 (3:2) so it appears stretched (or if your card supports non-power-of-two textures, then you can do it at native resolution), then dump out each frame to an image file. I don't have any code to hand, but OSG can cope with that easily. When you come to encode it, you can stretch it back to the desired resolution. Oh, and don't forget to make your animation dependent on framerate (i.e. assume you're running at a constant framerate), so the animation runs smoothly at full speed; otherwise you'll pick up any variation in rendering speed. To put it all together, Avid did a home edition of their video editing software that was free to download and is fairly powerful, but I can't find it on their page, maybe they stopped doing it. If you're on Linux, there's a free bit of software for video editing, called Cinelerra (http://heroinewarrior.com/cinelerra.php3 ). If you want to automate the process, and you use Linux, Transcode (http://www.transcoding.org/cgi-bin/transcode) will import individual frames and spit out a video in a bunch of different formats. It might take some time to set up to your liking, but it'll happily cope with most things you can throw at it; it'll even mux any audio you might want to use. John Donovan Sony Computer Entertainment Europe http://www.scee.com http://www.scee.com/ [EMAIL PROTECTED] wrote on 09/11/2006 00:45:14: Hello, PLEASE! Does anybody have a way to automatically create an mpg or avi from an OSG fly through? So, that it plays back in real-time? Basically,
Re: [osg-users] Updates to GraphicsWindowWin32
On Wed, 2007-01-24 at 10:07 +, Robert Osfield wrote: Hi All, André Garneau has kindly done some more work on GraphicsWindowWin32, these changes are now merged, so a cvs update will get them. Below is his post to osg-submissions, I'm reposting here so that window users can keep abreast of changes. Many thanks to André for his efforts. Robert. -- The following changes are included: * Setup proper pixel format for ATI boards (removal of WGL_SWAP_METHOD_ARB specification from the requested pixel format since unsupported by the ATI driver) * Fix to create sample OpenGL window on the proper display device. This is the temporary window used to choose the desired pixel format. In the previous version, this window was always created on the primary display device, even though it had potentially different pixel formats compared to the target display device containing the window to be created. * Implementation of WindowingSystemInterface::setScreenResolution() method * Implementation of WindowingSystemInterface::setScreenRefreshRate() method * Implementation of GraphicsWindow::requestWarpPointer() method * Implementation of GraphicsWindow::useCursor() method and associated trait support. This can be used in two ways; first, when the graphics trait requested indicates that no cursor should be present, a new cursor-less window class is used to create the window. When a cursor-enabled window creation is requested, another window class is used. After creation of a window, it is also possible to toggle the cursor state by using the GraphicsWindow::useCursor method. * The way the mouse behaves is now compatible with the behaviour seen on X11; i.e. when pressing a mouse button, the window where the pointer is located will capture the mouse input and release it only after the button has been released. This results in all mouse movement events being dispatched to the window where the button was pressed initially until it is released. This improves the interaction with graphics windows. * Preparation work has been done to support the ability of moving a window from one screen to another screen and recreating its rendering context when this happens. This has been tested with a mix of NVIDIA and ATI cards and works properly. For the moment being, this feature is commented out due to changes in the core OSG libraries that have been done but need to be submitted later this week for approval by Robert. Upcoming features * Support for moving windows from one screen to another screen seamlessly * Ability to set the window (i.e. the application itself creates the rendering window and passes it to the GraphicsWindowWin32 class) I don't use Windows anymore, but I remember when I did a while back how bad I wanted a graphics library that did this. :) I wasn't able to easily do it with ANY of the popular ones--they were all very aggressive and assumed that the window they created internally was the only one you'd ever want to use. Of course, this was a long time ago, and things may have changed in the Windows scene since then... * Other miscellaneous items ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgViewer::Viewer VS osgViewer::SimpleViewer
I'm cleaning up the osgsimpleviewerGTK demo (for resubmission) and I wanted to add the ability to toggle the stats display on/off. However, I realized the SimpleViewer object has no way of doing this, which led to a question: I've read the comments in the files, but I can't see the conceptual difference between the two. I can almost use them interchangeably, although osgViewer::Viewer doesn't actually display anything using the code that works for SimpleViewer. It would appear that the SimpleViewer class is much lower level than just the Viewer class, as it makes no attempt to create a window--only a context. At any rate--it should be very straightforward to add stats to SimpleViewer, right? How much interaction will it need (if any?) with the external windowing system--in my case, GTK? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: [osg-submissions] osgsimpleviewerGTK
On Tue, 2007-01-02 at 17:31 -0500, Jeremy L. Moles wrote: I noticed there wasn't a GTK version of the SimpleViewer and wanted to submit one. It uses gtkglext, which is available in all of the recent Ubuntu, Fedora, and SuSE releases. (Seeing as, er, part of my job is to know that kind of stuff. :)) Anyways, feel free to make it actually DO something OSG-wise, rather than just print out MENU: foo or BUTTON: bar. (For example, StateSet LINE mode on the node...) Hey Robert--was wondering if you'd had a chance to eyeball this yet? Does it meet the requirements as a submission? Do I need to fix it up any? ___ osg-submissions mailing list [EMAIL PROTECTED] http://openscenegraph.net/mailman/listinfo/osg-submissions ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgsimpleviewerGTK
I noticed there wasn't a GTK version of the SimpleViewer and wanted to submit one. It uses gtkglext, which is available in all of the recent Ubuntu, Fedora, and SuSE releases. (Seeing as, er, part of my job is to know that kind of stuff. :)) Anyways, feel free to make it actually DO something OSG-wise, rather than just print out MENU: foo or BUTTON: bar. (For example, StateSet LINE mode on the node...) osgsimpleviewerGTK.tbz2 Description: application/bzip-compressed-tar ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgsimpleviewerGTK
On Tue, 2007-01-02 at 17:31 -0500, Jeremy L. Moles wrote: I noticed there wasn't a GTK version of the SimpleViewer and wanted to submit one. It uses gtkglext, which is available in all of the recent Ubuntu, Fedora, and SuSE releases. (Seeing as, er, part of my job is to know that kind of stuff. :)) Anyways, feel free to make it actually DO something OSG-wise, rather than just print out MENU: foo or BUTTON: bar. (For example, StateSet LINE mode on the node...) Few things I didn't mention: - The code is setup so that the OSGGTKDrawingArea object is very reusable. It acts as both a GtkWidget AND an osgViewer::SimpleViewer. - Because of GTK's use of callbacks, it gets messy using class methods as functions for events. However, it can be done--and indeed, I use the only way I know how--so forgive the messy parts of that code. Also, osg-submissions bounced the first mail. Rightly so, I guess... teaches me to doublepost. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] [LONG] simple example about osg, gtkdrawingarea and glade
On Thu, 2006-12-21 at 16:49 -0500, Jeremy L. Moles wrote:
On Thu, 2006-12-21 at 21:46 +, Robert Osfield wrote:
Hi,
The easist way to do it is first have a look at the
osgViewer::SimpleViewer and osgsimple, osgkeyboadmouse and
osgsimpleview* examples in CVS. None of the these are gtk based but
it really shouldn't be hard to link it up once you see how the OSG can
be wired up to other toolkits.
You'll probably need to connect the GLScene object to an event called
display in a user-defined callback (at least that's how it works in
Python). This gets called once per frame, so it's where you'll use your
SceneView object to communicate with the current, implicit context.
Actually, my summation is off here a bit--I assumed that 1) you were
using GtkGlExt and 2) the Python API was 1:1 w/ the C library.
Apparently, in gtkglext, you give a widget GL capability (such as a
DrawingArea).
Ignore it for now and I'll work up a real example later...
If I make an example doing this, would it go in OSG? osgsimpleviewerGTK
or whatever?
Robert.
On 12/21/06, elekis [EMAIL PROTECTED] wrote:
hi all,
I have to do some simulations in c++, and for the first time, I have
to use the gtk and osg.
I have to use osg in a gtk window(drawingarea I suppose) and the
inteface is creating with libglade.
but I have lots of difficult.
is there any tutorial example or anything other stuff who can help
me to connect this three library ..???
for example. there is my glade file.
--
?xml version=1.0 encoding=UTF-8 standalone=no?
!DOCTYPE glade-interface SYSTEM glade-2.0.dtd
!--Generated with glade3 3.0.2 on Thu Dec 21 18:41:06 2006 by [EMAIL
PROTECTED]
glade-interface
widget class=GtkWindow id=window1
child
widget class=GtkDrawingArea id=drawingarea1
property name=visibleTrue/property
/widget
/child
/widget
/glade-interface
like you see it's just a simple window with a drawingarea.
and there is my c++ file.
--
#include gtk/gtk.h
#include glade/glade.h
int main (int argc, char **argv)
{
GladeXML *xml;
gtk_init(argc, argv);
glade_init();
xml = glade_xml_new(../ConfigFile/WindowsView.glade, window1,
NULL);
if (!xml) {
g_warning(problem while loading the .glade file);
return 1;
}
GtkWidget *window1 = glade_xml_get_widget (xml, window1);
gtk_widget_show (window1);
gtk_main();
return 0;
}
like you see too, it's not so complicate but How to connect the osg
with the drawing area.
is a drawing area I have to use (that's what I read, but how to use
gtkmm with it??)
thanks a lot.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Tesselator spelling error
On Wed, 2006-12-20 at 18:41 +, Robert Osfield wrote: Hi Paul, On 12/20/06, Paul Martz [EMAIL PROTECTED] wrote: The osgUtil::Tesselator class is spelled incorrectly; there should be two Ls. I could go through current CVS and change all occurrences, but I wonder how this would impact the user community? I'd especially like to see this fixed before the Quick Start Guide goes to print, so maybe the v1.3 timeframe, within the next few weeks. Ooh--what's Quick Start Guide? :) Spelling mistakes I normally apply the fix straight away, normally these are spotted by others, like yourself, and they either make the fix or I do it. It the case of osgUtil::Tesselator send me a corrected files and I'll merge them, and patch up any missing areas such as build files/introspection. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgCairo Ideas
Well, I've got the basics of it working, demonstrated in some screenshots here: http://cherustone.com/osgCairo The general gist is: // - osgCairo::SurfaceImage* image = new osgCairo::SurfaceImage(256, 256); osg::Texture2D tex = new osg::Texture2D(); tex-setImage(image); image-drawCairoFoo(); image-drawCairoBar(); image-drawCairoBaz(); image-dirty() / -- Basically, this lets you use images as a kind of canvas with OSG easily. This also means that with a few tweaks (that I'll have finished this week), OSG will be able to load SVGs, PDFs, and PostScript files as textures--not that anyone would want to use PDFs or PS files. :) Furthermore, I'll eventually make a high-level windowing wrapper around this that lets users create vector-based windows, widgets, and other UI-esque things. I already have a prototype for this called Egypt, but it's in Python and is very, very slow. :) (Think Flash-like interfaces in games) With enough polish, could something like this (osgCairo) go into OSG--or at least be listed on the website? I've followed the coding conventions as close as possible, though it was very easy seeing as how I already use OSG-style C++ in the first place. :) On Fri, 2006-07-28 at 12:06 -0400, Jeremy L. Moles wrote: I'm looking at integrating the Cairo (http://cairographics.org) vector graphics library into OSG via osg::Texture*. This will allow me to use the nice Cairo API (which I am very familiar with) to draw sharp, clean, vector-based HUDS on Textures using OSG. Before I get started though, I had a few questions regarding OSG and how it handles Textures. First of all, is going the texture route even the most optimal? Cairo supports many backends, but it's most basic backend is simply an image buffer with explicit format semantics. My idea was to inherit from osg::TextureRectangle and implement the Cario API in the subclass, which in turn will operate on the Texture's internal osg::Image object. This is all fine and dandy, except I'm not quite sure what to do when a user wants to change the internal image buffer and have that update the texture in VRAM. Recreating the texture, obviously, is out of the question. I guess my question then is: what is the basic strategy for using a Texture in OSG as a kind of interactive canvas? glMapBuffer/glUnmapBuffer seems like it would be nice in this case, though I've only ever seen VBO's used for vertex data. Is this a case where I need FBO's instead? I don't really know anything about them, but Googling leads me to believe they could be helpful here. The osg FrameBufferObject also looks promising, but I'd want someone else to push me in that direction before I wasted time on something unfruitful. Sorry if this is a dumb question... :/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
