Re: [osg-users] Convert to OSG without file path

[Tony Vasile]

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

[Alexandre Vaillancourt]

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

[Robert Osfield]

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

[Sebastian Messerschmidt]

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

[Tony Vasile]

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

[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

Re: [osg-users] Lightpoint behavior with DirectionalSector

[Renato Semadeni]

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] Direct OpenGL Callback RTT Not Rendering Correctly

[Kevin Pitstick]

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);
  

Re: [osg-users] Lightpoint behavior with DirectionalSector

[Robert Osfield]

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

[Renato Semadeni]

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

[Robert Osfield]

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