According to these post you can let the git tools automatically make a branch
for every pull request on github:
http://blog.scottlowe.org/2015/09/04/checking-out-github-pull-requests-locally/
https://coderwall.com/p/3dgwcg/github-add-remote-for-pulls-and-merges
Cheers,
Pjotr
--
R
The changed for VS2015 look good. I still get the following warning:
3>I:\Libraries\OpenSceneGraphTrunk\include\osg/GraphicsThread(45): warning
C4589: Constructor of abstract class 'osg::GraphicsOperation' ignores
initializer for virtual base class 'osg::Referenced' (compiling source file
I:\Lib
I'll see what I can do. I'm going on vacation tomorrow so I don't have that
much time. First I have resolved the errors so I can get OSG to compile with
VS2015, those are more important. Attached are two files.
- First is osg/Types: VS2015 now have stdint.h included. This generates erros
when in
Hi Robert,
Testing with the newly released VS2015 produced these 4 warnings for each file
that includes (directly or indirectly) osg/GraphicsThread this will lead to
hundreds of warnings:
1>I:\Libraries\OpenSceneGraphTrunk\include\osg/OperationThread(55): warning
C4589: Constructor of abstract
Would't this add cpu overhead for animations that are done playing because the
channels are still updating?
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61727#61727
___
osg-users mai
Hi Robert,
I tested a few of our scene's and till now there are no problems.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61638#61638
___
osg-users mailing list
osg-users@lists.opens
Due to some other work I won't be able to test this out today, but I'll try to
make room for it tomorrow.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61614#61614
___
osg-users maili
That sounds good. You might even want to have a map
somewhere in there, then you can see which of the nodes are already in the
cache and do not need further post-processing.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61571#61571
I have done some tests and it looks good so far. There is only one regression
here and that is that proxy nodes that are set to load immediately are never
looked up from the cache ever. This actually is the most common use case for us
for those types of nodes.
In our program we by chance had th
robertosfield wrote:
>
> I have been looking further into how to handle use of the object cache
> alongside the DatabasePager and believe the best option will be for the
> DatabasePager to disable use of object cache when it's loaded subgraphs and
> handle the initial query against the object
Because you also have to deal with subobject like proxy nodes and images that
you want to have in the cache option 2 and 3 will be pretty hard to implement.
Option one seems like the elegant solution as right now you can only activate
those post processing steps if you have a database pager (or
Hi Robert,
I'm still in the process of compiling, but I had a look at the code.
As I understand it an object is put in the registery cache by
Registry::instance()->readNode(), thats before FindCompileableGLObjectsVisitor
will traverse it. This means that you will get race conditions in
FindComp
Hi Robert,
I tried your fix and it exposed a bug in my fix :)
The problem is that the readObjectFields method will add the object to the
_identifierMap. So all the other instances of that image in the same file will
be replaced by the created dummy object. In my fix this was an dummy image and
Looks like the new code fixes the deadlocks.
Attached are my modifications to the InputStream to no modify images when they
come from a cache. Note that this is a quick fix.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61524#61524
I first got the deadlock on linux and only in release builds. On windows I was
able to reproduce it by placing a 1ms sleep line 403. Adding cancel helps but
then the thread will not do any clean up and valgrind spits out a 1mb log file
complaining about memory leaks. It's better to try to fix th
Hi Robert,
I saw that you put the new thread code on svn. I have experimented a little
with it and it seems to produce deadlocks on application shutdown for us. In
OperationThread::cancel you have replaced a while loop with a join. The problem
is that the previous code was periodically calling
robertosfield wrote:
>
> In the case when the image is shared it looks to me like the best approach
> would be to not allow any additional modifications to the image by the
> InputStream::readImage() method. Even if you added mutex locks around the
> write operations to the mutex you'd ended
Hi Robert,
You said that you were working with shaders. A race condition that looks like
the Texture2D::setImage example above can also happen with shaders in .osg
files:
The method Shader_readLocalData can get shaders out of a cache when files are
referenced. Then later in Program::addShader t
Thanks for the helgrind tip. I think I pinpointed the crash in our program,
this is working from trunk:
As said we have multiple files that reference the same image for a texture, I
have found two spots that can cause problems:
- In InputStream::readImage(bool readFromExternal) at line 777 the p
robertosfield wrote:
>
> There are some specific .osgb threading issues related to initialization of
> the wrappers. There is chance that you are hitting up against this. For my
> own work I'm not currently testing against .osgb and get problems so I
> believe the .osgb issues can be dealt w
Hi Robert,
We too have some trouble with the database pager. It all started after we used
DatabasePager::setUpThreads to use more threads. We get memory corruption but
only on linux. Tried to use valgrind but then the problem does not occur.
We are still in the process of pinpointing it down, s
This could be related to a report I made here
http://forum.openscenegraph.org/viewtopic.php?t=13992#60127
Then there are might be two bugs, one is that for osgx files it somehow does
not looks in the right directory and two is that it gives a parse error when an
image is not found.
Cheers,
Pjot
We did some tests with display lists and VBO's. For our scene's usually display
lists outperform VBO's because they have less cpu overhead in the draw
traversal. There is only one point (which is vendor/driver specific, we use
nvidia) is that with models with a large amount of vertices (extract
Hi,
According to
http://www.opengl.org/registry/specs/EXT/framebuffer_multisample.txt all your
attachments need to have the same amount of samples.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=60798#60798
___
Pjotr wrote:
> No they do not present itself in the 3.2 branch. One thing I just noticed was
> that osgt files created with the 3.2 branch failed to load in the trunk
> version.
>
> Cheers,
> Pjotr
Nevermind the last bit. That was me trying to read the file that I made to test
wrong image re
No they do not present itself in the 3.2 branch. One thing I just noticed was
that osgt files created with the 3.2 branch failed to load in the trunk version.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=60133#60133
__
I also noticed when profiling a scene with a lot of AnimationPathCallback that
dynamic casts make 1-2% of the total execution time (Visual Studio uses strcmp
when doing dynamic casts it seems). Almost all of this comes from
NodeCAllback::run and Callback::traverse. The question is are all those
Hi Robert,
A few small bugs I found in the trunk:
- loading osgb/osgt files that have references to images that do not exists
fail to parse (and sometimes I get a segfault) and the warnings produced are
not meaningful at all.
- saving classes that derive from osg::Image (like ImageSequece) seem
I was trying to save a file to .ive format today but that failed with the
message: "Unknown node in Group::write(), className()=Geometry"
So right now it looks like it's impossible to write to .ive files.
While osgt/osgb files work I looked at the code and noticed that the
osg::Drawable does not
With our distributed rendering setup we don't let the master run till all the
clients are connected. From there we send the master's FrameStamp (so frame
number, reference time, simulation time and just in case also the calender
time) to all the slaves every frame. To manage animations the maste
Yes that seems to work. But I think that the warning is meant to inform that
you could get unexpected behavior if you don't watch out as explained here
(http://stackoverflow.com/questions/11965596/diamond-inheritance-scenario-compiles-fine-in-g-but-produces-warnings-errors)
(see last example of
The warning is still there.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=59687#59687
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/list
It only fixed the warnings for set/getUserdata.
The warning for the run method still exist. It might be that Microsoft chose to
always output this warning.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=59683#59683
_
The warnings I get are:
ClusterCullingCallback.h(12): warning C4250: 'osg::ClusterCullingCallback' :
inherits 'osg::NodeCallback::osg::NodeCallback::run' via dominance
(..\..\..\..\..\src\osgWrappers\serializers\osg\ClusterCullingCallback.cpp)
I:\Libraries\OpenSceneGraphTrunk\include\osg/Callbac
I had to add OSG_EXPORT to osg::Callback and osg::StateSet::Callback to make it
compile with visual studio 2013. I did get a lot of warnings about the run
method being inherited via dominance from classes like ClusterCullingCallback.
But till now everything is working fine here.
Cheers,
Pjotr
License does not really matter. Same terms as the other examples is fine by me.
I don't mean to say to just depecrate the drawable callbacks without fixing
them. Of course we need to fix them, but we also need to deprecate them to make
clear to people that somewhere in the future those callbacks
Sure you can adapt and use it as an example.
As you can't have a Drawable::UpdateCallback on a osg::Node it sounds weird
that Node::setUpdateCallback(Object*) can accept a Drawable::UpdateCallback.
What do you do when someone passes a Drawable::UpdateCallback to a Node? I
rather have an compile
I made a little testfile with all the permutations of nodes/drawables and
updatecallbacks could come up with. The last two would never come up in old
code and maybe only by accident in new code.
It adds 7 update callbacks.
For me only 4 are called and the parent group says that only 3 children r
Might moving the logic over to the add/remove parent methods and making special
overloads for those methods in the drawable class be a solution? I don't know
if it's better at the end but at least this would at least remove the need to
have special handling of this in the setChild method (with a
Hi Robert,
While trying to add an update callback to a geometry node that was attached to
a lod without using a geode I stumbled upon some bugs:
If you use the Drawable::setUpdateCallback method to add a
osg::Drawable::UpdateCallback it will not fire because a group does not update
it's NumChi
Hi Robert,
I stumbled on a little bug with the new drawables. I was distributing points
data into different drawables that I used in a LOD later. When simplifying the
system to not use geodes anymore I came upon the following bug:
If Drawable::getBoundingBox would compute an invalid bounding box
I fixed that linker error for myself but didn't commit anything yet as I though
that it was a work in progress. I had to change include/osgUI/Export and
src/osgUI/CMakeLists.txt to make it compile on my system (visual studio 2013).
See the attached files.
Cheers,
Pjotr
--
Read
A side request, if you plan to keep the Bound struct can it be moved into it's
own file? Right now osg/Plane has to include osg/Node for the Bound struct.
Because osg/Plane is included by osg/Polytope which is included by osg/State
the recompile time increases a lot. In the osg project alone the
Our codebase consists of 350 files (50% are headers). There was only one place
where we were using the bounding boxes to draw a box around selected object to
highlight them as being selected. So when compiling without osg_use_bound we
had to change some getBound calls to getBoundingBox.
We of c
I have compiled osg successfully with and without osg_use_bound and everything
seems to work with our software. (For the record, I only had to change two
lines of code to make our software compile without osg_use_bound)
I must say that after thinking about this I share a bit of David concern. I
I tested the code in trunk with OSG_USE_BOUND defined and I now get crashes
when loading files. After some debugging it looks like expressions like these
(see Geode::computeBound() and Group::computeBound()):
bb.expandBy((*itr)->getBound());
do not work anymore because the compiler can not know
For me osgviewer.cpp and Renderer.cpp were not compiling (visual studio 2013
with profile GL2) because they were still using GLuintEXT. So I changed that,
see the attached files.
I also noticed that the generated OpenGL header were not copied to the
installation directory so my own application
I'm not familiar with the new osg(t/b) writers (we still use osg and ive here
but are also considering a switch) but looking at the commit log there was a
change in the revision 14099 that added a new way to serialize arrays to
support the lua plugin which seems to change the layout also.
Cheer
I think the problem with the generated file is that the vertex attributes begin
at 6 and the attributes 0 to 5 are null pointers and are not written. Then when
reading the reader expects 8 arrays but there are only 2 written so it messes
up reading them. I also noticed that, unlike in the osg fo
Hi Robert,
Reading ive files works. Only reading .osg files that contain vertex attribute
arrays does not work yet. (both the binding and the normalization can be set
before the array itself right now).
Cheers,
Pjotr
robertosfield wrote:
> Hi Pjotr,
>
> Could you do an svn update, rebuild an
Hi Robert,
I tried out your code and it won't load a lot of geometry files even if they
are using fast path. The problem lies in that with the old Geometry::ArrayData
structure you could first set the binding and then the array. Now you are
forced to do this the other way around. The ive reader
Hi,
Have you set the datavariance of the text to dynamic?
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54557#54557
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http:
Hi,
This is actually an issue with the visual studio 2012 library, see here for an
explanation: http://connect.microsoft.com/VisualStudio/feedback/details/733720/
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54332#54332
_
Hi,
Have you tried
camera->setImplicitBufferAttachmentMask(osg::Camera::IMPLICIT_COLOR_BUFFER_ATTACHMENT);
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=52975#52975
___
osg-users mailing lis
Hi,
We recently converted our stereo viewer to cull the scene graph in parallel.
But now we are having a crash with some models that have bump mapping effects
on them. The crash happens in Effect::traverse because both threads try to add
new techniques.
Is there a reason this is done during th
We had a similar issue. We had a stereo rendering setup that used slave
camera's to render the scene. The only thing the main camera did was to swap
the buffers.
Whats happened is when you do anything that will get bounding boxes of nodes
invalidated, if you don't recalculate those they will be
56 matches
Mail list logo
