Hi Dirk! I don't think there is anything hard about using fcdEdit! Actually, I think it's great to avoid the cut and paste errors that ALWAYS occur when creating new nodes.
I've come across some minor bugs using fcdEdit though. I'm using the 1.4 distribution on .Net2003. If you derive from a node that is not a system component an include referring to a system node is inserted anyway. #include <OpenSG/OSGNewNodeFields.h> The local include seems to be ignored too, in that case. It also inserted a lib define symbol even though I left that field blank. This seems to have been fixed in later versions though. But the first bug occurred in the latest daily build too. Another thing... I have compiled all my nodes into a static lib. How am I supposed to inform the loader, in an application using that lib, about the nodes? So that it can load a file with my derived nodes in it. Thanks /Fredrik -----Ursprungligt meddelande----- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Dirk Reiners Skickat: den 1 april 2005 23:18 Till: users Ämne: Creating New FieldContainer Types for Your Application (was: Re:[Opensg-users] LUT Volume Rendering) Hi everybody On Fri, 2005-04-01 at 09:28 +0200, Vincent Honnet wrote: > Hello Manfred, > > That's nice but for that I need to compile an inherited class and that's > what I can't do for the moment. just for kicks I tried doing that to get an idea if it's really that hard. So here's a step-by-step description of what I did: Alright, so we want to extend some OpenSG class. How do we do that? Well, just like any other C++ library: we derive from a class that we want to change, add some variables for our new data and override some methods. Variables in OpenSG are stored in the Base class, not in the actual class. To create the Base class source, we need an .fcd file, which describes the variables in the class, and the fcdEdit program to create the actual code. So let's get it. I downloaded and installed the current cl.net 2003 dailybuild and a source snapshot (it's always better to have the source when you're trying to extend something). The distribution contains an fcdEdit executable in the main directory, so I just started that. Given that I wanted to do something very similar to the DVRSimpleShader I just loaded its .fcd file as a base. (Source/System/NodeCores/Drawables/VolRen/OSGDVRSimpleShader.fcd). Noticed that it's pretty empty. :) Changed the Name to DVRSimpleFilterShader, that's what my new class is going to be called. I want to use the new FC in my own program, so it will not be a system component: uncheck System Component. We want to derive our new shader from the DVRSimpleShader, so change the parent to DVRSimpleShader, which is a System Component (i.e. part of the OpenSG core). Turned on "Use Local Includes" (which forces the use of "" instead of <> for #include), as I will have the generated files in my source directory and not in the system search path. I want to use the FC in my own program, so set the library to empty. Added two fields (minFilter and magFilter) to keep the parameter for the filtering modes that I want to set (yes, I know, in general the DVRVolume shaders are not supposed to have functional fields, but for this example it was easier to do it this way). Use GLenum as the type and 0 as the DefaultValue, leave Cardinality at Single (only one value per field, not a vector), Access at Public (I want the user to change it) and Visibility at Extern (I can't reconstruct this from other variables and I want it to be transfered across a cluster and written to .osb files). Ok, save the .fcd file to the Tutorials folder of the installation (as this is where I'm going to add the code). Pressed "Write Field Container Code" to generate an initial version of the class's code in the Tutorials folder. This contains some methods that all OpenSG classes need, e.g. to register themselves with the type system and supply some generic capabilities. This is the class that we're going to add our new features to later. Used "Write Field Container Base Code" to create the code for the Base class. This keeps all the variables I added. The Base code should never be changed by the user, as you might have to regenerate it later when we change something internal to the core library. Wrote that to the Tutorials folder, too. Exeunt fcdEdit, we're done with it. Now for the actual coding. Opened the Tutorials .dsw with VS.Net 2003. For testing I copied over testSimpleVolumeNodeRender.cpp into the Tutorials folder and used it instead of 01hello.cpp. Ran it (after adding "OpenSG/" to the includes). Works fine. Ok, now for the new code. Added the files that fcdEdit generated (OSGDVRSimpleFilterShader*.{h,inl,cpp}) to the project. Changed the test program so it creates a SimpleFilterShader instead of the SimpleShader and rebuild it. Compiles fine but does nothing new: no wonder, I haven't actually changed anything yet. So now for the last part: overriding methods. Which methods to override? Let's look at the SimpleShader for help. Looking at OSGDVRSimpleShader.h we see that there are 2 normal methods (changed and dump) and 5 virtual methods for volume rendering: initialize, activate, brickActivate, deactivate and cleanup. We will have to change/overload some of these. Looking at our newly generated OSGDVRSimpleFilterShader.h we see that changed and dump have been defined by fcdEdit already, nothing to do here. But which of the methods do we actually need to change? Manfred was nice enough to tell us that we only need to touch brickActivate. So let's do that: add brickActivate to the header and copy the empty one from OSGDVRSimpleShader.cpp into our new code. Now we add the code that Manfred mentioned, but we don't use the hard- coded filter modes, instead we use the fields that we added to our new class above: glTexParameteri( GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, getMinFilter()); glTexParameteri( GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER, getMagFilter()); Now we need to #include <OpenSG/OSGGLExt.h> to have the necessary defines, and we're done. Change the test program so that it sets the two variables to the values we want (GL_NEAREST), build, run and viola: point-sampled RGBA volumes. The code I generated is at http://www.vrac.iastate.edu/~dreiners/SimpleFilterShader.zip (SourceForge doesn't accept .zip attachments), you can use it as it is. Now the question is: what's so hard about this? I think nothing, really. The only complication compared to extending any other C++ library is that you have to use fcdEdit to generate the initial code and the Base files to keep the variables. But there's nothing really magic about it. Admitted, this is pretty much the simplest possible example, but it doesn't get much more complicated unless you want to do significant changes. I hope this helps more people over the hump of extending OpenSG. It's really not much different from any other library and tools like fcdEdit hide most of the complexity. Have a nice weekend Dirk -- -- Dirk Reiners OpenSG Forum [EMAIL PROTECTED] -- The OpenSG Open Source Scenegraph: http://www.opensg.org -- Join the list at http://lists.sf.net/lists/listinfo/opensg-users ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&opÿick _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
