Hello Johannes, Johannes Brunen wrote: >> Carsten Neumann wrote: >>> Johannes Brunen wrote: >> In 2 there is a ChunkOverrideGroup which allows overriding a specific >> chunk of a material. > That is good news. I'm excited... > > >>> 4. I have had problems with the "--jobs=4" switch of the scons > system. >>> Is this a known problem? Is it supported by OpenSG at all? >> ..., but for 2 I use -j4 all the time and it works fine. >> What problems did you have ? > > I have had build errors on incremental builds which did vanish when I > tried without the -j4 option. > > I just verified it as follows: > First I changed a cpp file from the system lib. Then I run the following > command from my shell > > ./scons --jobs=4 compiler=msvc71 type=dbg contrib_ply=yes > > which leads to the following error: > > LINK : fatal error LNK1104: cannot open file > 'Build\win32-msvc71\installed\lib\OSGSystemD.lib' > scons: *** [Build\win32-msvc71\Source\Contrib\OSGContribD.dll] Error > 1104 > scons: building terminated because of errors. > > Trying again the same procedure but with the command > > ./scons compiler=msvc71 type=dbg contrib_ply=yes > > does not show an error at all.
hm, looks like there is a dependency missing. >>> 5. Should I switch to OpenSG 2.0 framework or should I wait further? > ... >> ... >> The generic answer is something like this: If you don't need any of > the >> features that 2 lacks compared to 1, ... > > Oh, that is a difficult one for me. Can I read up what is still missing > from OpenSG 2.0 against 1.8. Is the content of > http://opensg.vrsource.org/trac/wiki/Dev/FeaturesToPortFrom1to2 > up to date? No, unfortunately not. The biggest thing that comes to mind are the more advanced shadow map variations, 2 only has an implementation of the basic algorithm. > Did anyone take the time to diff the branches? > However, I do not want to bother. OpenSG 2.0 is not released. So I will > be patient. > >> One exception is perhaps if you >> have some cores that do complicated stuff for rendering, ... > What are these? Sorry, I was a bit terse here. I was referring to NodeCores (the things that define the semantics of a node, e.g. Transform). If you have written your own ones (like MultiSwitch) and these interact with the RenderAction in non-trivial ways (*not* like MultiSwitch) you might have to adapt for the shader compositing framework Gerrit is planning. > Nevertheless, I will give the OpenSG 2.0 branch a try... Yes, please do. I would suggest taking a look at the contents of Examples/Simple or Examples/Tutorial (together with the parts of the online tutorial that are "ported") to get you started. >>> 7. Is it possible to build multiple build types (opt,dbg) >>> simultaneously? I tried "type=dgb,opt" but that doesn't work. >> probably not. Personally I'm not a big fan of this type of thing, >> because it makes the build system (even more) complicated and you can >> easily get the same thing by opening two consoles. > > I didn't know that it is possible to run two scons processes > concurrently on the same build system. hm, now that you mention it, I'm not sure if it is officially supported, but I did not run into any problems so far. [SNIP] >>> 9. Would it be of interest to support custom memory management > handlers? >> Sounds interesting as well. How does it integrate and how do you > control >> which mem management is used ? OpenSG basically uses new/delete, so to > >> affect it those would have to be replaced (globally). > Yes, that is exactly how it works. I simply link an object to the > libraries ('NewDeleteImpl.obj' and 'NewDeleteImplD.obj', rsp) providing > the globally defined functions: > > void* ::operator new(size_t size) { ... } > void* ::operator new[](size_t size) { ... } > void ::operator delete(void *pObj) { ... } > void ::operator delete[](void *pObj) { ... } > > These itself are delegating into my custum memory manager. This works > pretty fine and I use it all over my code. > >> Does this mem management give you performance benefits ? > > I can't answer that for the OpenSG code. For my application I could > actually measure a huge performance gain comparing to the standard > visual C++ memory manager. I use the > http://www.nedprod.com/programs/portable/nedmalloc/index.html as a base > and I'm pretty fine with it. An alternative is the Hoard memory > allocator http://www.cs.umass.edu/~emery/hoard/ which is a very fine > piece of software. > However, the reason for changing the default memory allocator for the > OpenSG (and other) library(ies) is not performance per se, but the > effort of centralizing the memory management and the possibility to > interfere the allocation proccess. For instance adding safe memory > blocks around a requested memory block, and later on testing these bocks > on some installed memory pattern can easily show memory corruption. Or > counting the actually used memory is always of interest. ok, thanks for the explanation. >> In OpenSG >> object creation is a rather expensive operation because of the > multiple >> aspect and registration stuff that happens. > Hmm,... > > >>> If there is any interest I could post this >>> file to the list. >> yes, please. Even if I don't get around to integrate it right away we >> have it in the archives and perhaps someone finds it interesting > enough >> to make similar changes for linux/os x ;) > So, here it goes... thank you. I'm somewhat busy ATM with stuff that has deadlines attached to it, so it might take me a while before I can integrate it. So if someone beats me to it... ;) regards, Carsten ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
