Thanks for the informative reply, much appreciated.
robertosfield wrote:
> I have run with the various command 1-8 options and get different behaviour
> but looking at the code I really don't know what is expected. The black cow
> is likely occurring because no shader is being provided that han
No worries, thanks anyway
http://www.hrwallingford.com/facilities/ship-simulation-centre
(http://www.hrwallingford.com/facilities/ship-simulation-centre)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72084#72084
I would be interested and grateful to know what you think of the (apparent) bug
I posted Robert, if you get a chance!
The code I posted should compile, and you just need to feed in different
numbers to the first command line arg to see the effects of changing the vertex
attrib and matrix unifo
I would run your app in debug mode, break in CullVisitor::apply(osg::Geode),
then take a look at the matrix stacks and see where the nans are coming from
http://www.hrwallingford.com/facilities/ship-simulation-centre
(http://www.hrwallingford.com/facilities/ship-simulati
Oops, forgot that most readers are on the mailing list. Here is the code which
breaks with vertex attrib aliasing:
Code:
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restr
I'm also transitioning a legacy GL OSG project with a mix of custom shaders to
modern GL bit by bit. And I've also had lots of trouble and headache with the
built-in modern GL vertex attrib aliasing setting.
It seems crazy that the official advice is to write shaders and use OSG just
like legac
Fair enough.. I do understand the frustration of supporting unfamiliar devs in
an FOSS project.
I already understand and agree with your post, but I think you took me wrong
I'm not making a big deal out of anything and value OSG highly.
Based on your post I'll move on to something more concre
Hi Robert,
For now it'd be too time consuming to isolate a test case. Supporting modern
OpenGL does seem like it would be more natural if you had some way of hooking
into the setting of the model matrix and vertex attributes so that you could
assign / name / alter them yourself.
Cheers,
Chris
The problem is whenever I try to use
gc->getState()->setUseModelViewAndProjectionUniforms(true);
gc->getState()->setUseVertexAttributeAliasing(true);
it always seems to screw up something, like the precipitation or particle
effects.
I figure if there is a way I can set the projection ma
Hi,
What is the proper way to set the view/projection matrix to a uniform yourself?
I've found that trying to deal with the osg_ built-in uniforms which do all
sorts of renaming etc is unreliable and would like to be able to just set
everything myself manually.
At the moment I'm setting the vi
Wow, can't believe my luck at stumbling into the solution for this so quickly..
Code:
osgViewer::Viewer::Windows windows;
viewer.getWindows(windows);
for(osgViewer::Viewer::Windows::iterator itr = windows.begin();
itr != windows.end();
++itr
I'm also having trouble with this, very frustrating.
http://www.hrwallingford.com/facilities/ship-simulation-centre
(http://www.hrwallingford.com/facilities/ship-simulation-centre)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.
Thanks Lionel & Seb, that's very helpful. When I tried setting ints to a
Sampler2D array it said that it couldn't take ints, which is why I thought it
wasn't supported. If I set to ints directly though it does work.
http://www.hrwallingford.com/facilities/ship-simulation
Thanks, I'll have to think about whether it would be feasible for me to spend
time in this project altering osg core..
See i do like texture arrays, they would be ideal, except that I'm dealing with
GIS data grids, so stretching/compressing them would lose information or memory
space. I want to
Hi,
Working on an app that is going to be doing a lot of work with large texture
processing, and will need to squeeze as much data into graphics memory as
possible and allow many textures to be referenced programmatically.
I've got texture arrays working, but can't use this for all requirements
We're at the classic commercial FOSS impasse where we both (and probably many
others) would benefit from this work, but whoever pays for it to be done loses
(especially if it's not accepted).
There are things we need done here more urgently that don't touch on core
osg/osgDB , so unfortunatly w
By the way while I have your attention is this how you would do a visitor to
access all images?
Code:
void ImageResizeVisitor::apply(osg::Node& node)
{
osg::StateSet* ss = node.getStateSet();
if ( ss )
{
osg::StateAttribute* sa =
ss->getAttribute(osg::St
Thanks Robert, that sounds like a better solution.
http://www.hrwallingford.com/facilities/ship-simulation-centre
(http://www.hrwallingford.com/facilities/ship-simulation-centre)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.ph
Thanks Robert, that sounds like a better solution.
http://www.hrwallingford.com/facilities/ship-simulation-centre
(http://www.hrwallingford.com/facilities/ship-simulation-centre)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.ph
Hi Rob,
Maybe you're looking at this on a mailing list? I just downloaded it
successfully from the phpBB site at:
http://forum.openscenegraph.org/viewtopic.php?t=15294
Let me know if that doesn't work for you and I'll put it somewhere else.
Regards,
Chris
http://www.hr
Just bumping this; anyone know what this change was about? I know we're going
to have this issue and have to remember to reapply the fix when we next upgrade.
http://www.hrwallingford.com/facilities/ship-simulation-centre
(http://www.hrwallingford.com/facilities/ship-sim
Hi,
We've had some troubles with stuttering when going from one screen to another,
and a big part of the problem seems to be that we have textures that aren't to
the power of two and need to be resized.
This resize happens right at the last minute before the data is sent to the
graphics card,
Hi,
Here is a screenshot which shows the bump map capability we're interested in,
but really what it does it let you set up a bunch of parameters and textures
which can be sent to your shaders. This way you can do modern rendering effects
from your FLTs:
[Image: http://i59.tinypic.com/2hqtdg4.
Hi,
I've started writing an update to the OpenFlight plugin to support the
"extended material" options in Creator, mainly so we can use the auto-generated
bump-map textures in our shaders.
I don't want to have to redo it every time there's an OSG update though, so I'm
wondering what the proces
It'd be good to resolve this, I just spent half a day tracking this issue down.
I eventually dug down to the error coming after glEnable(35866) was set, which
is GL_TEXTURE_2D_ARRAY_EXT, and then coming to this.
If setTextureAttributeAndModes could just detect a Texture2DArray
StateAttribute it
25 matches
Mail list logo
