Re: [osg-users] Avoiding sudden drawcall peaks
Hi, thank you for your detailed reply, Robert! Yes, you guessed right, I'm using Windows 8 ;) My hardware causing the trouble is a AMD-HD7970. I tested the program on a Nvidia gtx-970 and there where no frame drops at all! Although the hardware specs of the gtx are a bit better, I would have at expected at least some frame drops. So it really is a driver issue. I used the windows process explorer to verify, that memory is not unloaded from the GPU when looking at other directions, which did not happen on both machines. The main memory is freed after the upload, so setUnRefImageDataAfterApply does its job well. So it might be the frame caching issue. I will have a look into those sync settings you suggested, when I need to use a larger model. Until now, I'll just leave the culling disabled. Cheers, Max -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62717#62717 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk
Hi Glenn,
On 17 February 2015 at 21:56, Glenn Waldron gwald...@gmail.com wrote:
In my opinion the biggest problem that shader composition (SC) needs to
address is the code maintenance nightmare of having to copy, paste, or edit
other peoples' shaders in order to add your own functionality.
I don't we'll ever be able to get away from knowledge of other peoples
shaders, but if they are develop with adaptability in mind then extended
them is possible. An example below.
So I am eager to understand how you will address that. How can I add a new
shader component without editing the main() functions to support it? For
example, take the shaders in the terrain displacement code. I want to add
some gamma correction code into the fragment stage. Will I be able to do
that without editing your shaders too?
The way to tackle this would be to add entry points into the original
shader via defines and using this make it possible to add in the extra
features you want. For instance the fragment shader could look something
like:
#pragma import_defines(FS_BEFORE_MAIN, FS_START_OF_MAIN, FS_END_OF_MAIN)
uniform sampler2D baseTexture;
varying vec2 texcoord;
#ifdef FS_BEFORE_MAIN
FS_BEFORE_MAIN
#endif
void main(void)
{
#ifdef FS_START_OF_MAIN
FS_START_OF_MAIN
#endif
gl_FragColor = texture2D( baseTexture, texcoord);
#ifdef FS_END_OF_MAIN
FS_END_OF_MAIN
#endif
}
So if you want to inject a some kind of processing you could do something
like:
stateset-setDefine(FS_BEFORE_MAIN,uniform blendColor;
stateset-setDefine(FS_END_OF_MAIN,gl_FragColor = mix(gl_FragColor,
blendColor, blendColor.a););
One could simplify the shader code further if one provided defaults of
for the FS_* defines so you wouldn't need the #ifdefs. I have considered
adding support defaults support via #pragma
import_defines(FOR_PROVIDING_DEFAULTS=0), but have kept thing simple for
this first iteration.
There will be a limit to how can be done with shader composition without
replacing shaders wholesale, simple because complexity can quickly get out
of hand. When it comes to debugging shaders being able to review them in
their entirety is ideal, as soon as you start optionally adding bits in
knowing what might be going on diminishes. The use of defines like above
is preferable to trying to use generic code insertion (such as by using a
float as I did with osg::ShaderComposition) as even if you don't know what
the define will be substituted with you do at least know what order things
will be done in, and different blocks have specific meaning.
For osgTerrain displacement mapping it's possible to override the
GeometryPool::getProgram(..) so that you can subclass the pool and add in
your own osg::Program or add/substitute shaders into the program. This
gives one the ability to do the high level substitution or utilize the
#pragma(tic) shader composition or a combination of the two.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk
Hi Sebastian, On 17 February 2015 at 21:07, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: I'll update and test against my code.Don't hold your breath, though ;-) Anyways, thank you very much for this feature. If we manage to solve the other problems with this release (serialization and VPB) it might evolve towards a really great major one. Advocating for those, not wanting the old fashioned shader composition dying: I suspect I will run into problems as soon as I test the core-profile based stuff. In the old approach I do the BindFragLocation stuff based on the shader code parsed, which I cannot do anymore.But maybe there are ways around this. One idea popping into my head was to provide some createProgram callback inside the stateset to gain control over those aspects. This might remove the need for a ShaderComposer etc. Attached some example using merge (and changes avoiding GL_*). I changed the GL_ yesterday evening and just testing out your example modification with the merge everything works as before the addition of the merge code so hopefully means my fixes yesterday are working as intended. W.r.t serialization and VPB. I haven't yet added support for serialization for the StateSet define list - I'll add this once the functionality is a little more widely tested. I'm guessing you don't mean this though... If not then these discussions are for other threads. On the VPB side I checked in one fix from the community and one myself which got VPB back working on my system. Again these things are for other threads. W.r.t providing a StateSet::createProgram() this specifically wouldn't fit, but the general idea is something I've been wondering about. Rather than coming up with an elaborate ShaderComposition framework you just pass on the ability to customize Program, or collate Shader's in the scene graph into osg::Program. This isn't something I want to dive into right now though as it's orthogonal to the #pragmatic shader composition functionality. And frankly I just want to get OSG-3.4 out the door sooner rather than later. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Some thoughts on the new DisplacementMapping technique
Hi Sebastian, Just a heads up for changes I've just checked in relating to DisplacementMapping, I have moved the osgTerrain::GeometryPool pointer from osgTerrain::DisplacementMappingTechnique to osgTerrain::Terrain. I have made this change so that it's easier to local and manage the GeometryPool. I am planning to tweak the way that the osg::Program is assigned to the StateSet's, instead of having them distributed across on each tile I'll place the osg::Program in a StateSet assigned to the Terrain. I haven't worked out the actual method for this yet but should wrap this up today. My idea is that only the change bits of state will be assigned to the tile related StateSet, the shared state will remain at the root of the terrain which of course is the Terrain node itself. I'll update this thread once I've done this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] Indentation problem, OutputIterator::isEndl() no longer works after upgrading to Microsoft VC12 toolchain
Hello,
I was recently working on upgrading compilers from VC10 to VC12, and
came across the following regression when exporting *.osgt files.
VC10:
osg::Group {
UniqueID 1
Children 5 {
osg::Group {
UniqueID 2
Children 3 {
osg::Switch {
UniqueID 3
UpdateCallback TRUE {
osg::NodeCallback {
UniqueID 4
}
}
Children 2 {
osg::Group {
UniqueID 5
UpdateCallback TRUE {
osg::NodeCallback {
UniqueID 6
}
}
Children 1 {
osg::Geode {
snip
VC12:
#Ascii Scene
#Version 100
#Generator OpenSceneGraph 3.2.1
osg::Group {
UniqueID 1
Children 5 {
osg::Group {
UniqueID 2
Children 3 {
osg::Switch {
UniqueID 3
UpdateCallback TRUE {
osg::NodeCallback {
UniqueID 4
}
}
Children 2 {
osg::Group {
UniqueID 5
UpdateCallback TRUE {
osg::NodeCallback {
UniqueID 6
}
}
Children 1 {
osg::Geode {
snip
Notice that the indentation has changed between VC10 and VC12
unexpectedly. I have traced the problem to OutputIterator::isEndl() in
the osgDB/StreamOperator header. In VC10, the fn variable comes from
msvcp100.dll for all calls to isEndl(). In VC12, some calls show fn
coming from osg100-osgdb.dll, and some calls come from
osgdb_serializers_osg.dll. Thus, the std::endl() address does not match
(and the function returns false) if fn originates from
osgdb_serializers_osg.dll.
Applying the __sun workaround does appear to fix the problem. I am
leaning towards thinking that the address check logic is not portable
due to most of the functions involved being inline. This is particularly
problematic since the osgdb_serializers_osg library is explicitly
linked, and therefore, the one definition rule behavior cannot be
applied by the linker when linking the application or other OSG dlls.
Perhaps there is a better way to detect std::endl, or refrain from
having to detect std::endl entirely?
Regards,
Judson
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] Lua scripting
Hi, Long time I am trying to use lua scripting plugin without success. This is all my lua code : function test (string, double,matrix ) print(string) print(double) print(matrix) return osg.Matrixd end It's very simple, but output is still Lua error : attempt to call a string value. I think that in script is missing some require or somethig that tell Lua about OSG . I add as input parameter inputParameters.push_back(new osg::MatrixfValueObject(matrix,osg::Matrixf())); I thik lua doesn't know something about OSG, and I got errors in console. Can you tell me what is wrong ? I have idea about generating some glue with Swig generator , and build it with OSG (as simple DLL file), and use with require in lua script. But it doesn't work. Application crashed. Can you public simple lua test script with one funcion, which is used with [Examples osgprezentation] project ? On web there are no examples about lua scripting in OSG. Or can you tell me how to do some magic with osg and lua. I am using OSG for 3 years but scripting is very difficult for me, I need som explanation how it works together . Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62720#62720 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Lua scripting
Hi Martin, Which version of the OSG are you using? In svn/trunk and the recent OSG-3.3.x dev series there is a lua plugin which provides the Lua source code directly within the plugin as well as the glue to integrate the OSG with Lua. There won't be any need to use tools like Swig as the OSG's serialization support is used to expose the OSG class properties and methods for you. As a test could you build OSG svn/trunk and OpenSceneGraph-Data svn/trunk, put the OpenSceneGraph-Data directory on an OSG_FILE_PATH env var and then run: osgviewer ui/TabWidget.lua.90,0,0.rot cow.osgt What you should get is a cow in the low left of widget with a tab panel in it. You can drag the panel around via the title area, and resize it using the mouse scroll wheel in the title area. Clicking on the tab will jump you between the different elements. Note, the 90,0,0.rot is simply there to rotate the osgUI widget from being in the XY plane to the XZ plane. The cow.osgt isn't lua of course but should give a little 3d reference to it. Now this example TabWidget.lua script is just what I've used for testing. A more sophisticated usage of lua can be found with VolumeSettings.lua script. This is designed to be used as part of Present3D along with volume rendering. These scripts are all examples of using .lua as a pseudo plugin where the lua script creates scene graph objects, populates the scene graph with lua callbacks and passes back the scene graph. One can also create Lua scripts and assign these as callbacks to the scene graph. To do this you'd create your script/read it from a file (via osgDB::readScriptFile(myscript.lua); and then call this via creating script engine and then passing in the script to be run via ScriptEngine::run(..), or add as a callback to the scene graph by attaching the osg::Script to an osg::ScriptNodeCallback. Have a look at the include/osg/ScriptEngine for all these classes. The osgtransferfunction and osgpresentation examples are really just test beds that I've used when developing this functionality so aren't written for the purpose of education. You might be able to glean a little from these. I'm afraid there aren't any examples written specifically for teaching users how to use the scripting yet. While this will be a bit of hurdle it'll should be much easier to get to grips with than jumping through all the hoops that a tool like Swig would introduce. It's been quite a few months since last worked specifically on the lua code so I'll be a little rusty but hopefully will be able to point you in the right direction. If you do have problems then if you can put together an example that can be tested then it'll be easier for me to spot what might be going wrong. Good luck, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem of determining the intersection with the LOD
Hi, I was faced with the following problem. On the scene has LOD node. If you set the range from 0 to a certain date, then everything works fine. But if the range starts at a certain date 0, can not determine the intersection. And another problem. If the model is added to the LOD, say with a range of 0 - 10, and kept well away until it is greater than 10 (it is not displayed), the intersection with it still is. ... Thank you! Cheers, Alex -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62721#62721 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk
Hi Glenn et. al. Today I've been revisiting the osgTerrain::DisplacementMappingTechnique, GeometryPool and associated shaders to make better use of the new #pragma(tic) shader composition. I haven't completed this work yet, but attached are the two main shaders I'm working on, these are where the bulk of the different options are for handling different numbers of colour layers, optional height fields etc. are. I have been able to replace combine two original vertex main shaders into one, and four different fragment main shaders into one.I have attached the shaders to illustrate my work in progress. Previously the GeometryPool had to manage the selection between the different combinations of shaders and create a different osg::Program for each combination, while now I will be able to remove all this C++ code for management of shaders and replace with simply StateSet::setDefine(..) to toggle the various features on/off. This toggle on/off of features can be generic - just needing to know the name of the feature to toggle, it won't need to know about GeometryPool or where it's attached different Programs. This is big advantage as it decouples the C++ implementation details from the interface. The C++ implementation is also simpler so will be easier to understand and maintain going forward. Once I've got the DisplacementMapping/GeometryPool code sorted (hopefully by end of tomorrow) I'll check it all in and provide others a more complex illustration of how to use the new form shader composition. The work I did on osgVolume in 2013/14 managed it's own local management of different shader combinations - osg::ShaderComposition just didn't fit the problem I was trying to solve so ended up creating a local code to solve the problem. However, this work would be an ideal candidate for converting to use #pragma(tic) shader composition, implementing it should be able to remove C++ code and make the shaders easier to manage. Once I've done this it should also be an example that members of the community can use as inspiration. A note for Glenn, could you give me an example of what type of modifications to the attached shaders you'd like to add in - just sticking the GLSL code you want to add directly into the GLSL without any of the #ifdef etc. would be fine. Knowing what type of GLSL you want to inject will help me know what entry points would be useful to add to the shaders to give you the ability to customize them. Cheers, Robert. terrain_displacement_mapping.vert Description: Binary data terrain_displacement_mapping_CCC.frag Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.3.3/trunk won't load certain files
Hi Robert, can you have look into the issue?
I've attached two versions of the file.
The working one is created by simply using osgconv. The non-working
version undergone some traversing by visitors, optimizers etc.
Version is the current trunk.
I'll try to chase on my own to pinpoint the problem.
Cheers
Sebastian
I'm too deep in the shader work right now to pop up and take on
another topic, so will have to return to issues once this work is
wrapped up - should be in the next couple of days.
W.r.t serialization, work most of my testing I used .osgt and .osgb so
for a good range of uses it looks to be working fine but just ran a
quick test with your sign.osgt and it fails. I can't dive into what
might be wrong right now so can't provide an specific suggestions as
to what might be amiss.
Does the .osg format work OK for this data? If so could you post a
.osg version so that it can be compared.
W.r.t serializer changes since 3.2.x, the main changes have been to
make the serializers more flexible so that it enables the better
introspection capabilities required by scripting support. In theory
this changes shouldn't affect the reading/writing of .osgt and .osgb
files, but perhaps something has gone amiss here. What it might be I
can't say at all at this stage.
Robert.
On 3 February 2015 at 09:53, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de
mailto:sebastian.messerschm...@gmx.de wrote:
Hi,
I've just created some osgb/osgt files and most of them cannot be
loaded anymore. They are failing with
InputStream::readObject(): Unsupported wrapper class ☺
for osgb files and
AsciiInputIterator::readProperty(): Unmatched property Values,
expecting UniqueID
for osgt.
I've attached the file in binary and text flavour which are not
working for me.
Can someone please check if they are behaving the same on their
machines?
@Robert: It seems something got broken with the serialization
since the 3.2.x versions.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
#Ascii Scene
#Version 116
#Generator OpenSceneGraph 3.3.4
osg::Group {
UniqueID 1
Name db
UserDataContainer TRUE {
osg::DefaultUserDataContainer {
UniqueID 2
}
}
Children 1 {
osg::Group {
UniqueID 3
Name Entfernungsmesser_1000m
Children 1 {
osgSim::MultiSwitch {
UniqueID 4
Name s_visible
Children 1 {
osg::Group {
UniqueID 5
Name Entfernungsmarker_1000m
Children 2 {
osg::Geode {
UniqueID 6
Name p1
DataVariance STATIC
StateSet TRUE {
osg::StateSet {
UniqueID 7
DataVariance STATIC
ModeList 2 {
GL_CULL_FACE ON
GL_LIGHTING ON
}
AttributeList 2 {
osg::Material {
UniqueID 8
Ambient TRUE Front 0.427451 0.427451 0.427451 1 Back
0.427451 0.427451 0.427451 1
Diffuse TRUE Front 0.427451 0.427451 0.427451 1 Back
0.427451 0.427451 0.427451 1
Specular TRUE Front 0 0 0 1 Back 0 0 0 1
Emission TRUE Front 0 0 0 1 Back 0 0 0 1
Shininess TRUE Front 0 Back 0
}
Value OFF
osg::CullFace {
UniqueID 9
}
Value OFF
}
TextureModeList 1 {
Data 1 {
GL_TEXTURE_2D ON
}
}
TextureAttributeList 1 {
Data 1 {
osg::Texture2D {
UniqueID 10
WRAP_S REPEAT
WRAP_T REPEAT
WRAP_R CLAMP
MIN_FILTER LINEAR_MIPMAP_LINEAR
MAG_FILTER LINEAR
UnRefImageDataAfterApply TRUE
Swizzle RGBA
Image TRUE {
ClassName osg::Image
UniqueID 11
FileName
