Hi community,
anyone has experienced some weirdness with the latest drivers from NVIDIA?
My shaders just stopped working with them without any warning/error from OSG
...
-Nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi Trajce,
I have noticed issues with Shader compilation on 256 (and above) series on
Windows 7. Some fragment shaders using gl_LightSource fields were generating
internal compiler errors. In fact I also posted a bug report to NVidia. These
errors were normally reported by OSG with compilation
Hi John,
If you need this to setup uniforms for shadow fragment shaders then maybe
standard GL gl_FrontFacing variable could do the trick ? Its available at least
in GLSL 1.50 and above. I have not checked when it was introduced maybe its
available in earlier GLSL profiles.
Wojtek
From:
Hi Wojtek,
looks like that is it. The shader failing is the lighting shader ... Thanks
!
-Nick
On Thu, Aug 5, 2010 at 11:51 AM, Wojciech Lewandowski lewandow...@ai.com.pl
wrote:
Hi Trajce,
I have noticed issues with Shader compilation on 256 (and above) series on
Windows 7. Some
Hello,
is it possible to mix two different osg shadow techniques. I would like use the
parallel split shadow map for my terrain and the standard shadow map for my
vehicle.
Cheers
Martin
--
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.
Bis zu 150 EUR Startguthaben inklusive!
Hi guys,
thanks for all your answers. Unfortunately, I am leaving for a week
holidays in one hour.
Anyway, the problem is following:
- I am generating shadow volumes on the fly in cull visitor
- It works perfectly, except the cases when mirrors are used - let's
recall that mirror turns
I'm posting the solution to my problem should anyone encounter the same dumb
problem.
It appears I had left in my code a line that changed the root scene node every
frame. I think the particles may be reinitialized when the root scene node is
changed, so the particles never got beyond the first
Hello Mike,
So I've been prodding around a bit in the osgFX::BumpMapping code and noticed
that vertex and fragment shader programs are embedded in BumpMapping.cpp. I'm
guessing the TexMat ceases to do anything because the shader programs ignore
it? Is there any way to bypass that without
Hi Martin,
is it possible to mix two different osg shadow techniques. I would like use the
parallel split shadow map for my terrain and the standard shadow map for my
vehicle.
No, that won't work. At least not easily.
The shadows from your vehicle needs to be cast on your terrain, and if
Hi,
I wanted help with setting these five camera parameters: focal length, f, the
location of the image in pixel coordinates (o_x, o_y), the effective pixel size
in the horizontal and vertical direction (s_x, s_y)? How can I set these is
osg??
Thank you!
Cheers,
Ricky
--
- Kris Dale a écrit :
ReaderWriterPNG.obj : error LNK2019: unresolved external symbol
png_get_io_ptr referenced in function void __cdecl
png_read_istream(struct png_struct_def *,unsigned char *,unsigned
__int64) (?png_read_istream@@YAXPEAUpng_struct_def@@pea...@z)
I fixed that by
Hi Torben,
I haven't decided on what the remote side architecture would be. I was not sure
if I needed to have a full fledged PC on the remote side or could I get away
with using a monitor connected to a device that receives the wireless video
feed.
Not having a full fledged OC on the remote
Hi,
I've got a texture mapped geometry in a scene that I'm shooting rays at. I'm
using the osgUtil::IntersectVisitor::Hit structure to get at the drawable that
was intersected. What I really need is the color of the polygon at the
intersected point. I have the hit point location in world
Sanat Talmaki wrote:
If you replace this monitor with a video transmitter hardware, you could send this local rendered output to your reciever monitor.
I'm sorry but I don't know how this could be achieved (what parts)?
Try Googling for video transmitter. There is hardware available
Dear OSG community,
As you may know, VT MÄK is the vendor of the VR-Vantage visualization
product line, which is based on OSG. We would like to invite you, the
members of the OSG community, to participate in a visualization innovation
contest that we are sponsoring. We are offering cash
Hi Sanat,
Ok, letts assume you don't use a full fleged pc but a single monitor on the
remote site.
Instead plugin this monitor directly to your pc, you plaug teh video
rtansmitter on the pc and the monitor on the video receiver.
e.g
Frederic Bouvier wrote:
- Kris Dale a écrit :
Kris Dale wrote:
Afternoon all!
I'm having a bit of an issue I've never run into before trying to build
OSG. Hoping someone can point me in the right direction.
I have all of the image library .libs and includes in a
Hi Torben, Jason
Thanks for the explanation, I clearly understand the video transmission part
now.
But using a set up such as that, I am basically transmitting the entire video
feed to the remote screen.
I am interested in sending the rendering of only 1 of those 3 viewports(1 view
from the
Hi Sanat,
But using a set up such as that, I am basically transmitting the entire video
feed to the remote screen.
I am interested in sending the rendering of only 1 of those 3 viewports(1 view
from the compositeViewer), not all 3. (as seen in the attachment below). With
that being the
Hi Skylark,
Thanks for your reply
Are there any examples in the source that show how to only render the bottom
left viewport on the second monitor (basically a generic example for
selective rendering) or any suggested reading ?
Thanks
Sanat
--
Read this topic online here:
Hi Sanat,
Are there any examples in the source that show how to only render the bottom left
viewport on the second monitor (basically a generic example for selective
rendering) or any suggested reading ?
See the osgcompositeviewer example.
In general, a CompositeViewer has a list of Views,
Thanks Jean, I'll try this out right away using a cable for the remote screen
for now.
-Sanat.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=30571#30571
___
osg-users mailing list
The sync blocks on a swap buffers call, not on the first OpenGL call (unless by
accident it's an actual OpenGL blocking call).
Non-blocking OpenGL calls run asynchronous on the back buffer (traditional
double buffering).
A glGet call is an actual OpenGL blocking call as it forces a pipe flush.
My own research indicates that the timing rules are:
The first opengl call will block if the back buffer is not available at that
point.
The swapbuffers will block if there is already a pending swap queued (by the
last call to swapbuffers)
So, depending on the circumstances, both can block.
I'm talking traditional/typical double buffering, not special cases.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Lilith Bryant
Sent: Thursday, August 05, 2010 5:27 PM
To: OpenSceneGraph Users
25 matches
Mail list logo