Re: [osg-users] Convert to OSG without file path
Hi Alexandre, Your right, but you could use osgconv to strip the paths in a temporary flt file and then convert the temporary flt file to osg. Tony V -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66401#66401 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert to OSG without file path
Tony, Thanks for your answer. Correct me if I'm wrong, but isn't this option used when you want to output .flt files? I'm trying to output .osg files. Thanks! -- Alexandre Vaillancourt 2016-02-23 7:44 GMT-05:00 Tony Vasile : > Hi Alexandre, > There is an export option for the OpenFlight plugin > "stripTextureFilePath". This should would do what you want. > > > Tony V > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=66396#66396 > > > > > > ___ > osg-users mailing list > 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
Re: [osg-users] Lightpoint behavior with DirectionalSector
On 23 February 2016 at 12:08, Renato Semadeni wrote: > Hi Robert > > Thanks a lot for point me to the source code responsible of handling the > lights. I will take a look at it later on. > > Just another question: Would it be possible to control multiple lights > with the same directional sector? > The LightPoint::_sector is just a ref_ptr<> so can happily share a single Sector instance between multiple LightPoint. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] "Request received" emails
Hi Tony, It happens for the mailing list too (I guess the reply-mail for the forum post is related to the duplication to the mailing list). It seems that you get one every time you post something of the forum. I posted two things tonight and got two of these. Tony V -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66397#66397 ___ osg-users mailing list 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
Re: [osg-users] [forum] "Request received" emails
It seems that you get one every time you post something of the forum. I posted two things tonight and got two of these. Tony V -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66397#66397 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert to OSG without file path
Hi Alexandre, There is an export option for the OpenFlight plugin "stripTextureFilePath". This should would do what you want. Tony V -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66396#66396 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lightpoint behavior with DirectionalSector
Hi Robert Thanks a lot for point me to the source code responsible of handling the lights. I will take a look at it later on. Just another question: Would it be possible to control multiple lights with the same directional sector? Kind regards, Renato -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66395#66395 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PFFLT_GSTATE_TABLES equivalence.
Is there an equivalent of this Performer call to the following:
>
> The function, pfdConverterMode_flt, is provided for affecting the
> behavior of the loader.
>
> void pfdConverterMode_flt ( int mode, int val );
>
> PFFLT_GSTATE_TABLES - Selects the number of "indexed pfGeoState"
> tables to handle/create while loading databases. Values greater
> than zero cause the loader to call pfGSetGStateIndex(3) instead
> of pfGSetGState(3). A value of zero or one is otherwise the
> same in terms a storage behavior. The default value is zero,
> meaning the loader will call pfGSetGState(3) to bind pfGeoState's
> to pfGetSet's.
>
Code:
// The Shared Palette must be accessed in the app process.
fltSharedPalette* plt = fltGetCurSharedPalette();
pfList* rnd = (pfList*)plt->rendMap->renditions;
// If we do not have multiple renditions (geostate tables) then
// do not attempt to get the ir channel.
if (rnd->getNum() > 1)
{
// Tell Performer to use the IR GeoState table for rendering the models,
// for the channel.
pipe->getChan(0)->setGStateTable((pfList*)rnd->get(1));
// Also force the table to be used in the app process, so that any app
// processing which needs to parse the geoStates will have valid data.
pfGeoState::applyTable((pfList*)rnd->get(1));
// reference table, so that other processes (eg DBASE) can set it
// for there use.
_irGStateTable = (pfList*)rnd->get(1);
}
Tony V
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66394#66394
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Direct OpenGL Callback RTT Not Rendering Correctly
Hi all,
I am running into issues using direct OpenGL calls inside a camera's pre-draw
(or post-draw) callback while having the camera render into a framebuffer
object. The texture is bound to a geode which is displayed in the default
framebuffer on screen. The OpenGL calls should render an animated scene, but
the texture is only updated once at the start. When using a post-draw callback,
the texture is not updated at all.
For simplicity's sake, I'll describe and post the code of a simple example that
demonstrates my issue. Here's the setup:
- A CompositeViewer with two Views sharing the same context.
- One View's camera is set up to render into a framebuffer object and is
attached to a color texture and a packed depth-stencil texture. Its render
order is set to NESTED-1. It has a pre-draw callback on it that performs OpenGL
calls, but it does not do any rendering itself (no scene data, clear mask set
to 0).
- The other View's camera renders to a single screen (default framebuffer). Its
scene data is a square geode that is attached to the texture as its scene data.
Its render order is set to NESTED-2 to occur after the render-to-texture.
- The OpenGL callback is pretty simple. It pushes the OpenGL state, sets up the
viewport/scissor, clears the buffer, sets the frustum, draws a rotated square,
and pops the OpenGL state. The rotation changes with each call with the intent
of drawing a rotating square to the screen.
This direct OpenGL pre-draw callback works great if it is attached to a camera
that is rendering to the default framebuffer (no render-to-texture). With
render-to-texture, the square is shown in its initial rotation state but does
not spin. If I use a post-draw callback instead, nothing is drawn at all.
A few more notes:
- I am using OpenSceneGraph 3.4.0 and have seen this behavior on both on a
Macbook Pro (OS X 10.11) as well as on an Nvidia TX1 running Ubuntu 14.04.
- I have verified that the callback is being executed every frame.
- I have tried setting dirty on the Image as well as dirtyBound on the texture
geode's geometry with no success.
- When using a pre-draw callback, calling dirtyAttachmentMap on the RTT camera
has the desired effect; however, it appears to reconstruct the FBO which I do
not want to do every frame. Also, using this method does not fix the behavior
of the post-draw callback.
My guess is that I'm missing a flag or a setting that will cause the scene
graph to update appropriately.
Here is the full code for my example:
Code:
#include
#include
#include
#include
#include
#include
void pushState() {
glPushAttrib(GL_ALL_ATTRIB_BITS);
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glMatrixMode(GL_PROJECTION);
glPushMatrix();
glMatrixMode(GL_TEXTURE);
glPushMatrix();
}
void popState()
{
glMatrixMode(GL_TEXTURE);
glPopMatrix();
glMatrixMode(GL_PROJECTION);
glPopMatrix();
glMatrixMode(GL_MODELVIEW);
glPopMatrix();
glPopAttrib();
}
class OpenGlCallback : public osg::Camera::DrawCallback {
public:
OpenGlCallback(int width, int height) :
width(width), height(height) {}
virtual void operator()(osg::RenderInfo& renderInfo) const override {
static double xRotate = 0.0;
static double yRotate = 0.0;
static double zRotate = 0.0;
pushState();
glEnable(GL_SCISSOR_TEST);
glViewport(0, 0, width, height);
glScissor(0, 0, width, height);
glClearColor(0.3, 0.3, 0.3, 1.0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glMatrixMode(GL_PROJECTION);
GLfloat zNear = 0.5f;
GLfloat zFar = 20.0f;
GLfloat fov = 40.0;
GLfloat aspect = float(width)/float(height);
GLfloat fH = tan(float(fov/360.0f * osg::PI)) * zNear;
GLfloat fW = fH * aspect;
glFrustum(-fW, fW, -fH, fH, zNear, zFar);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glTranslatef(0.0, 0.0, -4.5);
glColor3f(0.7, 0.1, 0.1);
glRotatef(xRotate, 1.0, 0.0, 0.0);
glRotatef(yRotate, 0.0, 1.0, 0.0);
glRotatef(zRotate, 0.0, 0.0, 1.0);
glScalef(1.0, 1.0, 1.0);
glBegin(GL_POLYGON);
glVertex3f(-0.5, -0.5, -0.5);
glVertex3f(-0.5, 0.5, -0.5);
glVertex3f(0.5, 0.5, -0.5);
glVertex3f(0.5, -0.5, -0.5);
glEnd();
popState();
renderInfo.getCurrentCamera()->dirtyAttachmentMap();
xRotate += 1.0;
yRotate += 1.0;
zRotate += 1.0;
}
private:
int width;
int height;
};
osg::ref_ptr createColorTexture(int width, int height);
osg::ref_ptr createDepthStencilTexture(int width, int height);
osg::ref_ptr createTextureGeode(int x, int y, int width, int
height);
int main(int argc, char** argv) {
osg::ref_ptr viewer = new
osgViewer::CompositeViewer();
viewer->setThreadingModel(osgViewer::CompositeViewer::SingleThreaded);
osg::ref_ptr drawView = new osgViewer::View();
osg::ref_ptr oglView = new osgViewer::View();
drawView->setUpViewOnSingleScreen(0);
viewer->addView(drawView);
viewer->addView(oglView);
Re: [osg-users] Lightpoint behavior with DirectionalSector
On 23 February 2016 at 09:13, Renato Semadeni wrote:
> Hi Robert
>
> Thanks a lot for the quick answer. And yes, I forgot that I could change
> the osg code and recompile it from scratch.
>
> The behavior was just bizarre, since there was no symmetrie between the
> behavior on the left side of the two lights compared to the right side.
> Since it would be obvious that it could be a geometric problem. But what we
> found was that the position in the frustum seems to be the souce of the
> behavior.
>
The direction vector between the eye point and the light point is used to
calculator intensity of the light point in the sector calculation, so one
would expect the things to change as the light point moves within the
frustum. The code that does this is in LightPointNode.cpp, note the if
(lp._sector.valid()) block at the bottom of the extract I've posted below.
// delta vector between eyepoint and light point.
osg::Vec3 dv(eyePoint-position);
float intensity = (_lightSystem.valid()) ?
_lightSystem->getIntensity() : lp._intensity;
// slip light point if its intensity is 0.0 or negative.
if (intensity<=minimumIntensity) continue;
// (SIB) Clip on distance, if close to limit, add transparancy
float distanceFactor = 1.0f;
if (_maxVisibleDistance2!=FLT_MAX)
{
if (dv.length2()>_maxVisibleDistance2) continue;
else if (_maxVisibleDistance2 > 0)
distanceFactor = 1.0f - osg::square(dv.length2() /
_maxVisibleDistance2);
}
osg::Vec4 color = lp._color;
// check the sector.
if (lp._sector.valid())
{
intensity *= (*lp._sector)(dv);
// skip light point if it is intensity is 0.0 or negative.
if (intensity<=minimumIntensity) continue;
}
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lightpoint behavior with DirectionalSector
Hi Robert Thanks a lot for the quick answer. And yes, I forgot that I could change the osg code and recompile it from scratch. The behavior was just bizarre, since there was no symmetrie between the behavior on the left side of the two lights compared to the right side. Since it would be obvious that it could be a geometric problem. But what we found was that the position in the frustum seems to be the souce of the behavior. Kind regards, Renato -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66391#66391 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lightpoint behavior with DirectionalSector
Hi Renato,
The light point functionality was indeed written a long time ago, over a
decade me thinks, so I'm rather rusty on the topic.
Having a near light point appear/disappear at different times to a distant
one would be a function of the sector you define for it, so if this is not
happening how you'd expect my guess would be a problem in the values of the
sectors. The easiest way to understand what's going on would be to add
some debugging code to light point code that tests the sector whether the
eye point is within the sector or not and see if the behaviour is what you
are expecting.
Robert.
On 22 February 2016 at 13:49, Renato Semadeni wrote:
> Hi,
>
> I'm looking into an older implementation of osg. I struggling with some
> lightpoint which have directionsectors defined.
>
> I have lightpoints which change their appearance due to viewing position
> of the eyepoint. As you can see below, we are defining some lights in a
> .osg file, this is loaded by our engine and the lights are displayed.
>
>
> Code:
>
> Group {
> name "Lights_PAPI"
> nodeMask 0x
> cullingActive FALSE
> num_children 2
>osgSim::LightPointNode {
>nodeMask 0x
>cullingActive FALSE
>num_lightpoints 1
>minPixelSize 0
>maxPixelSize 10
>maxVisibleDistance2 20e+010
>pointSprite FALSE
>lightPoint {
> isOn TRUE
> position -21.5745 -336.3172 0.8935
> color 1 0 0 1
> intensity 0.04
> radius 5.5
> blendingMode BLENDED
> osgSim::DirectionalSector {
> direction -0.572689 -0.819772 0
> angles 6.28318 0.13614 6.28318 0
> }
>}
> }
> osgSim::LightPointNode {
>nodeMask 0x
>cullingActive FALSE
>num_lightpoints 2
>minPixelSize 0
>maxPixelSize 10
>maxVisibleDistance2 20e+010
>pointSprite FALSE
>lightPoint {
> isOn TRUE
> position 44.2707 -379.8886 0.8936
> color 1 0 0 1
> intensity 0.04
> radius 5.5
> blendingMode BLENDED
> osgSim::DirectionalSector {
> direction -0.572689 -0.819772 0
> angles 6.28318 0.13614 6.28318 0
> }
>}
> }
> }
>
>
>
>
> We observe now, that even if the lights are only at different positions,
> that always the one on closer on the x-axis gets turned off earlier than
> the other one.
>
> I was looking for an error in our code, but even in the osgviewer the same
> behavior is present. Secondly I tried to find an approach to define the
> directionsector once for both lightpoint. But unfortunately without any
> success.
>
> We can't include the light behavior into our engine, without larger
> effort, therefore we are looking for a solution base on the osg file format.
>
> I really hoping to find some help!
>
> Thank you!
>
> kind regards,
> Renato
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=66383#66383
>
>
>
>
>
> ___
> osg-users mailing list
> 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
