Re: [osg-users] [osgPlugins] Troubles with OSG 3.1.5 and ffmpeg 1.0.1
I think I've got it! Thanks to a note I've found in the ffmepg doc (the platform.html file), which says: Note that using import libraries created by dlltool requires the linker optimization option to be set to References: Keep Unreferenced Data (/OPT:NOREF), otherwise the resulting binaries will fail during runtime. This isn’t required when using import libraries generated by lib.exe. This issue is reported upstream at http://sourceware.org/bugzilla/show_bug.cgi?id=12633. I did that on the OSG ffmpeg plugin project and now everything works fine. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54003#54003 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Troubles with OSG 3.1.5 and ffmpeg 1.0.1
As a side note, I've also tested it with FFMpeg v1.1.3 and it works fine. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54004#54004 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] Troubles with OSG 3.1.5 and ffmpeg 1.0.1
Hi, I've just compiled OSG 3.1.5, on Windows7; I'm using ffmpeg v1.0.1, downloaded from http://ffmpeg.zeranoe.com/builds/win32/shared/. When I run osgmovie on any movie file, I get an error dialog saying cannot find computeDataVariance@Object@osg in avformat-54.dll and then the plugin fails loading. If I run the same exact command in debug (osgmovied) everything works fine! Note that I don't have debug libs for ffmpeg, so in both cases I am using the same DLLs... Any idea of what could possibly be the cause? Thanks a lot, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53930#53930 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Troubles with OSG 3.1.5 and ffmpeg 1.0.1
I'm on VS2008. I'll try looking into the compiler settings. Weird, anyway, as before I was on OSG 3.1.0 with ffmpeg 0.8 and it worked fine. luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53936#53936 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPPU] delay in glow FX
Hi,
I was trying to implement a glow effect and I was experiencing a bad delay
between the glow image and the main one. Then I looked back at the osgppu_glow
example and it looks like the same issue is also present there. To make it more
visible I have modified the example code a bit (you have my version attached
here). If you try moving the camera quite quickly you'll see the two images
showing some delay (the main render should never pop up from the green glow,
but it does). Weirdly enough, it seems that the glowed image updates FASTER
than the main one...
Any idea about what could cause this issue?
Thanks,
Luca
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43227#43227
/* OpenSceneGraph example, osgprerendercubemap.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osgViewer/Viewer
#include osg/Projection
#include osg/Geometry
#include osg/Texture
#include osg/TexGen
#include osg/Geode
#include osg/ShapeDrawable
#include osg/PolygonOffset
#include osg/CullFace
#include osg/TextureCubeMap
#include osg/TexMat
#include osg/MatrixTransform
#include osg/Light
#include osg/LightSource
#include osg/CullFace
#include osg/Material
#include osg/PositionAttitudeTransform
#include osg/ArgumentParser
#include osg/Camera
#include osg/TexGenNode
#include osg/Texture2D
#include osgPPU/Processor.h
#include osgPPU/UnitInOut.h
#include osgPPU/UnitOut.h
#include osgPPU/UnitCameraAttachmentBypass.h
#include osgPPU/UnitCamera.h
#include osgPPU/ShaderAttribute.h
#include osgPPU/UnitDepthbufferBypass.h
#include osgDB/ReadFile
#include osg/Program
#include osg/Shader
#include iostream
float gBlurSigma = 3.0;
float gBlurRadius = 7.0;
float g_NearPlane = 0.01;
float g_FarPlane = 50.0;
//--
// Create scene with some geometry and apply proper shader for needed objects
// return group node containing the scene, also return by reference geode, which should glow
//--
osg::ref_ptrosg::Group createScene(osg::Node* glowedScene)
{
using namespace osg;
ref_ptrGroup scene = new Group;
ref_ptrGeode geode_1 = new Geode;
//scene-addChild(geode_1.get());
ref_ptrGeode geode_2 = new Geode;
ref_ptrMatrixTransform transform_2 = new MatrixTransform;
transform_2-addChild(geode_2.get());
transform_2-setUpdateCallback(new osg::AnimationPathCallback(Vec3(0, 0, 0), Y_AXIS, inDegrees(45.0f)));
//scene-addChild(transform_2.get());
ref_ptrGeode geode_3 = new Geode;
ref_ptrMatrixTransform transform_3 = new MatrixTransform;
transform_3-addChild(geode_3.get());
//transform_3-setUpdateCallback(new osg::AnimationPathCallback(Vec3(0, 0, 0), Y_AXIS, inDegrees(-22.5f)));
scene-addChild(transform_3.get());
const float radius = 0.8f;
const float height = 1.0f;
ref_ptrTessellationHints hints = new TessellationHints;
hints-setDetailRatio(2.0f);
ref_ptrShapeDrawable shape;
shape = new ShapeDrawable(new Box(Vec3(0.0f, -2.0f, 0.0f), 10, 0.1f, 10), hints.get());
shape-setColor(Vec4(0.5f, 0.5f, 0.7f, 1.0f));
geode_1-addDrawable(shape.get());
shape = new ShapeDrawable(new Sphere(Vec3(-3.0f, 0.0f, 0.0f), radius), hints.get());
shape-setColor(Vec4(0.6f, 0.8f, 0.8f, 1.0f));
geode_2-addDrawable(shape.get());
shape = new ShapeDrawable(new Box(Vec3(3.0f, 0.0f, 0.0f), 2 * radius), hints.get());
shape-setColor(Vec4(0.4f, 0.9f, 0.3f, 1.0f));
geode_2-addDrawable(shape.get());
shape = new ShapeDrawable(new Cone(Vec3(0.0f, 0.0f, -3.0f), radius, height), hints.get());
shape-setColor(Vec4(0.2f, 0.5f, 0.7f, 1.0f));
geode_2-addDrawable(shape.get());
shape = new ShapeDrawable(new Cylinder(Vec3(0.0f, 0.0f, 3.0f), radius, height), hints.get());
shape-setColor(Vec4(1.0f, 0.3f, 0.3f, 1.0f));
geode_2-addDrawable(shape.get());
shape = new ShapeDrawable(new Box(Vec3(0.0f, 3.0f, 0.0f), 2, 1.1f, 2), hints.get());
Re: [osg-users] [osgPPU] Fix picture freeze for certain camera perspectives.
You're right, I've just tried a clean checkout from the trunk with OSG 3.0.1 and everything compiles files, including Alexander's fix. Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43161#43161 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] Fix picture freeze for certain camera perspectives.
Hi, Cool to see this fixed. Did you post this on the osgPPU trunk? I don't seem to see any recent change there... By the way, what version of OSG are you using to compile it? I just tried osgPPU 0.4.2 with OSG 3.0 and there seem to be a few changes to make to make it compile. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43148#43148 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] bug in Viewer::setUpViewerAsEmbeddedInWindow?
Hi, While using the Viewer::setUpViewerAsEmbeddedInWindow() I saw a possible problem with it. If you setup your viewer that way, all GUI events seem to bring incorrect information about the window size. This is because that method does not call GUIEventAdapter::setWindowRectangle() while the other setup methods do call it. So for example a call to ea.getWindowHeight() will always return the default 1024 value, no matter what your window size actually is. Is that a bug or is that the way it is supposed to work? Cheers, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42446#42446 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
Looking at the code I seem to understand that statistics use only the fixed pipeline. At least this is what I see in osgViewer\StatsHandler.cpp in setUpScene(). If that is true, then the first step is to change that behavior so to use shaders instead. About the precision declaration, that is just one single line to add at the beginning of the fragment shader (something like precision mediump float;). It could be ifdef'ed to add it only when GLES2 is available. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42273#42273 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
Jorge Izquierdo Ciges wrote: Another issue is missing statistics, probably HUD shader is needed. No shaders - no hud. Hi, I see that the stats HUD does not work in GLES2 and I see this post a few months old. Did anything change in that area since then? If not, I will try to find a fix/workaround and let you know in case I succeed. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42257#42257 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device
Big news!!! I've been able to make the OSG example run on my Honeycomb device! Now, something is definitely screwed somewhere... here is what I did in order to make it run. - build for API platform 9 both OSG and the examples - build the example ONLY for armeabi, not armeabi-v7 - target Android 2.3.3 in the Eclipse build. By doing that the code runs fine. To me, this means that previously my Honeycomb device (Acer IconiaTab) was trying to load the armeabi-v7 version, as it should support it, but for some reason that build is not working. Forcing it to use the armeabi (by removing completely the build for v7) works fine. This is where I have to stop though... if you guys are in touch with the Android Dev community and know well enough the depths of OSG build for Android, you might want to see if and how this can be fixed... I am available to run more tests of course, so let me know if there is anything else I can do ok? In the meantime I'll finally go on with some real coding :) Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42182#42182 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device
Hi Jorge, Actually I did already change that, so to compile for platform-10 even. But no success either. If you think that it might help to try explicitly with platform 9 I will. But I seriously doubt that it can help... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42159#42159 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device
I actually used 10 for both (OSG and the example). Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42162#42162 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device
Searching on many forums it comes out that other people do have similar issues with that linker warning. Not sure if that is related to the execution errors that we have (see original post from Ricky) but there might be a relation. Somewhere it was mentioned that the _dso_handle thing is defined in libc.a; and if you look at the stack traces posted by Ricky the libc is always mentioned on the very top of the list... Could it be an issue with the new NDK release? Maybe something is messed up in the way it handles these things? I'm not such an expert in gcc compilation so I cannot help that much here, sorry about that... Luca PS I'd like to try using the NDK r5b which apparently did not show these warnings. Any idea where I could get it from? The official NDK page only offers the link to the latest version -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42166#42166 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device
Hi, Yes, I will run more tests on this next week, trying to figure it out. In the meantime, I noticed one warning when linking the JNI part of the GLES1 example (libosgNativeLib.so) for armeabi-v7a: Code: ld.exe: warning: type and size of dynamic symbol `__dso_handle' are not defined Searching a bit on this it looks like a potential problem. I have no idea if this gives any clue to people, I just wanted to report it for now. Will dig more into it... Thanks! Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42125#42125 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device
I'm on NDK r6, the latest one. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42129#42129 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Write the Android example exclusively in C++
Hi, Did anybody do any further test in using purely native code with OSG? I've just made a simple thing: I've taken the native-activity example from the NDK (r6) and made sure it compiles and run fine. Then, changed a bit the Application/Android mk files to make sure they have the proper paths, then just added a single line of code to the main.c, to include an OSG header (anyone is fine...). The compiler starts screaming with errors like this: Code: ref_ptr:19: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'osg' Weirdly, it seems to happen anywhere there is a namespace keyword... Any idea what could cause that? Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42130#42130 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Write the Android example exclusively in C++
Stopid me... the file had a .c extension so the compiler was not trying to treat it as C++ code... Renamed it to main.cpp and now works fine :) Sorry... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42131#42131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG for Android
Hi Jorge, So, that means that I am doing thing in the correct order. After some more test I found out the problem: it's something in Cygwin. If I use relative paths instead of absolute ones everything works fine. No idea why and I don't want to investigate further, but at least now I know it's a cygwin-specific thing... Thanks! Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42106#42106 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG for Android
Jorge Izquierdo Ciges wrote: ... About the other things probably is just that you didn't do a make install to create a directory with all the includes etc Hi, I also have some issues with the example, basically the same as Riccardo. I did run the make install on my OSG build and it went OK (everything was installed under /usr/local/). But running the build command on that Android.mk still does not find the header files, unless I explicitly add an entry to the LOCAL_C_INCLUDES to add the standard osg/include tree. No idea why it works for you and not for us... A question: did you create your Android build in a separate folder (in my case under the OSG root) or did you do in source. mixing the new stuff with what comes out of SVN? Now on to the next issue: linker... I get this error: Code: ld.exe: cannot find -losgdb_dds Of course that lib as well as all the others are present in my build tree (and I indicated it correctly in the Android.mk file). Any idea what could cause these issue? Last but not least, is everybody using the ndk-build command to compile the example? Or is there another solution maybe going through CMake? I'd like to make sure that I do the things I'm supposed to... Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42101#42101 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: Normal unit amount method Normal 2 1.0 Tangent [...] Does this sound reasonable to you? That would be perfect, so go ahead with that. Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39590#39590 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid,
I gave it a try, the description lines are there. I just see a minor issue: you
did not add the MaterialData.{h,cpp} to Cmake.
About the results, looks like what is there is fine! I'll do more testing in
the next days, trying to use the definitions in my shaders as well, and let you
know.
One more thing. it looks like you now have code to handle the normal maps also.
But I think there is still no way to know if you were using a bump or a normal
map for the Bump channel. While in Max there is a clear distinction (different
texture types there), the exporter does not distinguish them. Look at this
example:
# osgmaxexp material data
NameTestMat
Map Diffuse 0 1 images\\casaterr_02.tga
Map Specular Level 1 1 images\\testRefMap.tga
Map Bump2 0.5 images\\casaterr_01norm.tga
# osgmaxexp material data
NameTestMat2
Map Bump0 0.3 images\\casaterr_01norm.tga
The testMat2 is using the tx directly as a bitmap, while TestMap first has a
NormalMap texture, then the bitmap. In the output they look totally equivalent
though. Looking at the code, it seems that you treat them as separate cases:
so, what about adding an extra field at the end of TestMap to indicate it's a
normal map? The field could actually be even smarter and indicate the active
texture space (tangent, screen, ...).
Great work anyway, really thanks for this.
Luca
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39530#39530
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, hi Jean-Sébastien, I'll let you choose the separator, even if I'd vote for tabs or vertical bars, not spaces. About where to place the descriptions and the syntax for them, let's keep in mind that each description is treated as a separate string, so I'd say each one must bring all the info it needs. Which now seems to include also the material ID. So each line should probably be something like (still using bars for now): Material_32|Diffuse|Unit_0|myFile.jpg|80 It's true we could have quite a bunch of these depending on how many materials are in your exported file. But if we can't have them on the single stateset, then to me it would much better to see them all in a single place rather them spread on various geodes. This could mean we will see a long section in the beginning of the file that contains ALL the material definitions for the whole file. The code on our side would just have to get the root node of the imported file, get all these description and process them in a single shot. And even for debugging purposes, being able to open the file and check all the materials at one is easier. Bottom line for me is: everything at the root node is better... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39497#39497 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: Regarding the format, are you suggesting that there should be a single description string that contains information for all the materials? Or each material should still be a separate description, but include the material name on each map entry line? I'm suggesting that we have one line per each map; so if you have 5 materials each with 3 maps you'll see 15 description lines in total. And each line should include the material ID it refers to so it's straightforward to parse (each line carries all the info you need, regardless of other strings). Then, as each node (so, in our case, the root node) can have multiple description strings (it's a vector), we can choose if we pack all the lines as a single string, if we group them by materials or if we have one string per line. Maybe we can make a few tests and see what is easier to read; but they are functionally equivalent anyway. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39505#39505 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: # osgmaxexp material data Name Basketball Map Diffuse 0 1 imagesbball_diffuse.jpg Map Bump1 0.3 imagesbball_normal.jpg Cool! I'll give it a try tomorrow (I'm in Europe, different time...). Just to be sure I've got it right, the fields after the keyword Map are, in order: map name, tx unit, blend amount (in [0,1] range), file name. Is that right? Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39514#39514 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Ciao, So, looks like we have a decision, cool! To summarize, if I've got it right, for every texture map in the material we will find a description string like the following (assuming we use the | as a separator): Diffuse|Unit_0|c:\program files\whatever\file.png|80 where: - the first field is the texture map name followed by a | sign; - the second field is the map file name, followed by a | sign - the third field is the blend amount (in the [0-100] range) Any additional parameter that might be needed by the specific channel would just be an additional field (and it would be up to the parser to know its meaning of course). Is that right? Note that I would avoid the = and just use the | to separate all fields; this makes it easier to tokenize the string (I'm lazy...). About bump, as far as I know Max allows you to create for that channel a map of type normal and therefore you should be able to distinguish between regular bump mapping and normal mapping. Actually Max allows even to specify what space to use for the normal map (tangent, local, screen...) so maybe we could even add that extra param in the description string. Anything we can do here to help on this, apart from testing? Can't wait to give it a try... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39447#39447 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
vezza wrote: About bump, as far as I know Max allows you to create for that channel a map of type normal and therefore you should be able to distinguish between regular bump mapping and normal mapping. Actually Max allows even to specify what space to use for the normal map (tangent, local, screen...) so maybe we could even add that extra param in the description string. I've made a few tests with the current (trunk) version of the exporter and I'd say it doesn't handle the normal maps for now. In Max, to use a normal map you don't assign directly a bitmap to the bump channel, you first create the map of type normal, then assign the bit map to it. So there is an extra texture node to go through. I guess the exporter could be extended to check if the bump texture is not a bitmap in which case it could try to interpret is as a normal map. No idea how to do it though as I don't know the max SDK ... :( Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39455#39455 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: The description would be added to the osg::StateSet object. Our use of the word material is referring to the Max material object. Mmm... StateSet does not derive from osg::Node so it does not have the DescriptionList member... So are you planning to extend the StateSet class, its serializer and so on? Or did I miss something?... Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39463#39463 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi, I have no idea about the new metadata stuff. But if that doesn't work, wouldn't it be easier to just move the description stuff from Node to Object? The name is already in the Object class, having the description there too would make a lot of sense anyway. And I don't this this would be a major refactor, right? Of course we need Robert's buy-in for this. For sure I would avoid using the name to encode all that info, that would really be ugly. I'd rather go back to the idea of predefined mapping among map channels and texture units... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39482#39482 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi, I'd like to share a few comments about the OSGExp for Max (I've recently sent them directly to Farshid, and also on the Delta3D forum, but it's probably better to share them here). I see a few limitations right now and the main ones are the following: - you can only export diffuse and light maps, no other texture that you might have in your material (e.g. bump/normal and specular); - the exporter does not have a predefined texture layer for every texture; i.e., if you just have a constant diffuse color and a light map, that texture will go to TextureUnit 0; if you have both a diffuse and a light map, the first will be on Unit 0 and the lightmap on Unit 1. For creating shaders this is quite annoying as you cannot make a safe assumption of where your textures are. And it gets of course more problematic if we add more maps like bump/normal, reflection, ... (As a side note, the Blender exporter is fine for this, every map is always assigned to the same unit, no matter what texture combination is used for the specific material.) Also, as OSG is changing quite a lot and as even the underlying geometry structures are evolving (VBOs for example), this may mean that the exporter could need an update even at that level. Is there any plan in that direction? Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39398#39398 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, Thanks for the reply; about the new version that can export all maps, that is surely great news, I'll have a look as soon as possible and get back with feedback. Farshid Lashkari wrote: I have two ideas to help with this issue: 1) Add an option that will use fixed texture units for all the standard map types. (ie. unit 0 contains diffuse, unit 5 is self-illumination, etc..). Not sure how this would work with composite materials though. 2) Add a specially formatted description string to the stateset that tells what map type each unit contains. The benefit of this approach is that other map related settings can also be saved (e.g. blend amount). I'd say that both options are interesting; the first one is probably more straightforward, but it's true that the second one opens more possibilities. What about a radio button in the exporter options to choose which strategy to use? I know this means coding both version but it would leave more margin on the end-user side... Thanks, Luca PS About the reply that bounced, no idea why, I'll look into that. Thanks for letting me know. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39429#39429 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: I'd like to avoid the first method, since it introduces a couple issues. As I mentioned in my last email, how would composite materials be handled? Should the assigned texture unit for each map type be customizable, and if so, how would the interface for assigning the texture units work? If you are not concerned with composite materials and are fine with hard-coded texture units, then this seems like something I can add soon. I'm not too clear about the composite material issue you mention: what is exactly the problem you see? And how is that case handled today? Anyway, what I would like from the standpoint of who uses the exported geometry is a well-defined way to interpret the material definitions. As I mentioned, if you export an object from Blender you have a clear mapping between texture units and map types. This is probably the easiest way for me to start coding my shaders. It requires writing additional maps compared to the diffuse+selfIllum ones you can write today; and with a well-defined way to know which maps you have in your material. Something else we should probably keep in mind is backward compatibility, in the sense that what was exported by the previous version should look similar to what we can write today, as many people have probably built code to parse materials and create shaders. Maybe we could start by assigning units 0 and 1 for diffuse and self-illum, as this is what you were getting before in most cases. And then use higher layers for the newly exported channels. Maybe for the new description strings we still need more brainstorming but let's start it :) Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39432#39432 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: Should the assigned texture unit for each map type be customizable, and if so, how would the interface for assigning the texture units work? About the texture unit - map type mapping, is that something that you really need on a per-material basis or is it more of a global definition for you whole file? I would say it's more a global thing. If so, we could have in the export dialog a choice between the predefined (hardcoded) mapping - like the one I was suggesting in the previous post - or a custom one (to be defined in some way still to be decided...). Then you may write it as a description string for every material (but if you do all materials will have the same string I guess). Of course the description string is still a great idea for everything that is specific to a given material instance (like the blend values you were mentioning). As this is fully Max-specific, the syntax to use could rely on Max definitions; for example, use the texture type IDs from the Max SDK to indicate the blend amount (ID_DI=0.7) and leave it up to the end-user code to do whatever it needs with that. Does this make sense? Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39434#39434 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
We could probably start off with the hardcoded version first, then later on add the customizable version. Baby steps... :) About the description syntax, I think the main decision is: is this a Max-specific feature or do we want it to be generic? Generic would be better of course but then we have things like the blend amount which is max-only... And to be generic we need the buy-in from the whole OSG community (ideally other exporters should use it too); and this may take some time. My vote then is for a Max-specific thing, using the SDK definitions and putting everything on a single line. A syntax using something like texture_ID=texture unit, blend value; for example: - ID_DI=Unit_0, 80 Simple and clear, a single line for each map... And if later we need to add other info about each map, just append them there. My 2 cents. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39438#39438 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] animationPath from Blender?
Hi, We would need to create anim paths in Blender and export them, so to attach them to some objects (a camera, a moving truck, ...). While the Max exporter handles anim curves properly and exports animationPaths, it seems that this is not feasible in Blender. I've also checked out the latest version of the script and apparently this feature is not supported. Can anybody suggest a way to get around it? We would like our paths to be generic enough, so to be used with more than one object (imagine a library of predefined anim paths that you can link to any object you like...). Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34676#34676 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgExp: problems with user properties?
Hi, I'm using the latest osgExp version and I see a problem in user properties. Try the following: - create a sphere - add some user properties to it - export it with default settings: everything should be fine - export it tagging the Flatten Static Transform on: the properties don't show up. I guess this is due to the fact that the flatter optimization removes some of the transforms. I think this is a problem because that option is heavily used to optimize exports and I would say the exporter should be able to maintain the user properties in some way, at least when - like in this case - there is not a complex hierarchy. Do you see any chance in solving that? Also, I have no idea if Max supports that, but is there a way to have user properties on materials rather than on geom and transform nodes? That would allow to set useful info about the shaders to build for each stateset. Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34461#34461 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] HDR example: wrong average luminance?
art wrote: the syntax is exactly the same as on usual texture2D call. So texture2DLod(sampler, coordinate [,lod]). So in both shaders luminance_adapted and luminance_mipmap, just change the texture2D calls to texture2DLod where mipmap level is accessed. Hi Art, Just retried the 0.4.2rc1 tag and still no luck... I still don't get what I expect as the average luminance. I'm on Windows7 right now so I'd like to give it a try on WinXP as well. if I get a different behavior I'll let you know. By the way, I don't think that clamping to zero the log values is correct. Even if you keep the negative values, at the last level you'll exp them and this will certainly bring them back to the positive realm. So actually the clamp is introducing an error I think. Luca PS Note that the specs for OGL 3.x say that Texture2D is a deprecated syntax, you should just drop the 2D (also for the Lod version). However that is not solving the issue either... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27458#27458 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] HDR example: wrong average luminance?
Hi, cool, I'll give it a try as soon as I can. Out of curiosity, can you post here the syntax of the call to texture2DLod you used? I'm on 0.4 for now and I'd like to test on it, later I'll switch to the trunk. Thanks! Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27375#27375 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] HDR example: wrong average luminance?
art wrote: Lucca, could you please try to change the texture2D () operations in the shaders which access last mipmap level (i.e. level 100) to an texture2DLod function. This might help. Hi Art, No luck... just tried it and it does not help. Actually the lod function does not produce any error message even if used in the fragment code, but it seems to retrieve wrong values (I always get a white pixel now). I think the problem is really in the mipmaps then; I remember I had something similar in another situation (accessing any texture mipmap always returning the base level), can't remember how I fixed it or what caused it... I'll dig in some older code to see if I can retrieve it. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27263#27263 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] HDR example: wrong average luminance?
Hi all, I have been playing a bit with osgPPU, and I have a couple of questions/issues. Note that I am on the last stable reelase, that is 0.4, so I don't know if there are more recent changes in the trunk that might fix these things. The main problem I have is with the HDR example, which I believe does not behave correctly. I'm referring to the osgppu_hdr example for my tests. The tone-mapping part has some problems and after some analysis I think it comes from the average luminance computation. To check that a problem is there, try disabling the temporal adaptation from the luminance_adapted_fp.glsl shader (just change it at the end so to set lum = current). This way the instant average luminance will be used for the tone mapping operations. Then run the program, display the average luminance result with F5; then zoom out so to reduce a bit the teapot. Try then panning around so to move the teapot in different parts of the image and you will see sudden changes in the luminance values, which are not correct. The shader tries to read the last value of the mipmapped texture for the sceneLuminance unit. But from what I see, it looks like this does not work and it actually reads the zero level, i.e. the full texture. In fact, when you move the teapot around keep an eye on what's in the center of the image: the shader samples at (0.5, 0.5)... When nothing is there you'll get a black luminance (well, a dark gray, there is a lower clamping at 0.2 in the shader). An additional test you can do to verify the problem is to change the sampling point of the texture from (0.5, 0.5) to anything else. If you are reading the last mipmap level (1x1 texture) this should always retrieve the same value, while it doesn't. Does anybody know if this is really the problem I see? If it is, any solution or any idea about how to address it? Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27189#27189 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] HDR example: wrong average luminance?
josselin wrote:
Hi Luca,
The way I found is :
1. compute the log10 values of the entire texture in a first shader
2. then perform the mipmap with:
osgPPU::UnitInMipmapOut* sceneLuminance = new osgPPU::UnitInMipmapOut();
sceneLuminance-setName(ComputeSceneLuminance);
{
sceneLuminance-generateMipmapForInputTexture(0);
}
3. get the 5th or 6th level of the mipmapped texture, and perform the
mean of this texture in a shader. You'll got your average luminance.
Hi Josselin,
I don't think your solution is correct, the log should be computed only on the
first level. And in general I think that the whole example is fine from an
algorithm standpoint (it basically matches 1:1 the HDRLighting sample you get
with DirectX SDK, with some minor changes).
The problem is really in accessing the last mipmap level of that luminance
texture. I have no idea if this goes wrong because the mipmaps are actually not
there of for some other reason.
Also, for Allen, the error is not so evident thanks to the temporal adaptation
which tends to mask it. But if you disable it the problem will be well visible
I think.
Luca
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=27251#27251
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
