Thanks a lot ,I already do these in a update callback. But blink continue
exist.
This is my code:
ResultCode ExpCntl::startPaint(HINSTANCE hinstance)
{
ResultCode rslt = SUCCESS;
DWORD paintThreadID;
HANDLE paintThreadHandle;
paintThreadHandle = CreateThread(NULL, 0, PaintThread,
Hi Alejandro
Im not 100% here, but I think you still need to specify some sort of
projection basis, even plain lat lon uses some defenition of the geoid like
WGS84 og similar.
Natrally it could be a problem with you GTiff file.
What version of VPB OSG are you using?
Brgs.
Ralf
2008/10/27
Hi Alejandro,
VPB is only understand well referenced WGS84 formatted data. So I advice you
to use referenced images to create your terrain, if you are not familiar
with reference data manipulation on images you should download prepared
referenced data from http://seamless.usgs.gov/index.php or
Hi, YangXiao
What have you done to your widget handle (hWndPaint) in rootCallback? Please
do not update the handle by yourself.
Also plz don't send such long code here. It brings trouble to others ...
Wang Rui
2008/10/27 YangXiao [EMAIL PROTECTED]
Thanks a lot ,I already do these in a update
Hi Umit,
On Mon, Oct 27, 2008 at 7:36 AM, Ümit Uzun [EMAIL PROTECTED] wrote:
VPB is only understand well referenced WGS84 formatted data.
This is not correct, VPB can handle a wide range of projections,
including no projections if your manually provide the projections.
However, I would very
Hi Robert,
Thanks for clarification. But I remember that, VPB can manipulate only WGS84
referenced data. But it may be valid for only BlueMarble viewer. Sorry for
wrong comment :)
Best Regards.
Umit Uzun
2008/10/27 Robert Osfield [EMAIL PROTECTED]
Hi Umit,
On Mon, Oct 27, 2008 at 7:36 AM,
Hi Umit,
On Mon, Oct 27, 2008 at 9:25 AM, Ümit Uzun [EMAIL PROTECTED] wrote:
Thanks for clarification. But I remember that, VPB can manipulate only WGS84
referenced data. But it may be valid for only BlueMarble viewer. Sorry for
wrong comment :)
When building geocentric databases VPB
Hi Cedric,
I'm excited about the prospect of an LGPL'd osgAnimation. I tried
checking out the animtk repository with mercurial, but no luck:
% hg clone http://hg.plopbyte.net/animtk
requesting all changes
adding changesets
abort: could not import module directory!
transaction abort!
rollback
Hi,
I have written a new class which inherit from osg::Group.
I have written a plugin for the .osg file format, that works fine.
I need to write a plugin for the .ive file format.
My initial thought was to copy-paste the ive::LOD code and replace the actual
read/write parts according to my
Hi Viggo,
I'm afraid the .ive format is not extensible, the only way to add to
it is to directly modify the sourceof the ive plugin.
Long term I want to introduce a binary .osg format that is extensible,
but I don't have the time available right now to tackle this.
Robert.
On Mon, Oct 27, 2008
Hi John,
I guess it comes from the version of mercurial you are using.
I tried because of your post, and it works.
hg clone http://hg.plopbyte.net/animtk
destination directory: animtk
requesting all changes
adding changesets
adding manifests
adding file changes
added 323 changesets with 1620
Hi Robert,
I guess i can use the same branch of Jeremy to start the integration.
Most of the time I interact with Jeremy so using the same branche is
good for me.
I will follow your suggestion for integration.
Cheers,
Cedric
Robert Osfield wrote:
Hi Cedric,
On Fri, Oct 24, 2008 at 6:52
This problem was solved in the past.
http://groups.google.com/group/osg-users/browse_thread/thread/b9725f6566bd92f3/700f0659ed89598e?lnk=gstq=animate+model#700f0659ed89598e
Please search the group before posting. Hĩ ;)
___
osg-users mailing list
Hi Melchior,
On Fri, Oct 24, 2008 at 8:36 PM, Melchior FRANZ
[EMAIL PROTECTED] wrote:
* Robert Osfield -- Friday 24 October 2008:
But it doesn't really say anything about the how the texture wrap
modes map to this, if at all.
I can't say that either, but the current situation is bad.
Thanks Cedric,
Instead of using the pre-built binary (version 0.9.4), I downloaded and
compiled mercurial from source (version 1.0.2), and clone (a.k.a.
checkout) worked like a charm. Hope this is helpful for other first-time
mercurial / animtk users;)
Best regards,
John
Cedric Pinson
Hello,
I'm trying to get working stereo for a three sided CAVE. I use a stereo
matrices callback which overrides the stereo matrix calculations in the
osgUtil::SceneView class. But i only can see the output for the right buffer,
the left buffer will never used. I printed out with
Hi,
I'm receiving an out of memory error while trying to scale an image.
File : Image.cpp
Line : 839 (2.6.1)
In Image::scaleImage(), gluScaleImage() returns 1285 : out of memory.
Any ideas?
Can
___
osg-users mailing list
Usually this means you don't have an active GL graphics context, which
unfortunately gluScaleImage requires. -gw
Glenn Waldron : Pelican Mapping : http://pelicanmapping.com :
+1.703.652.4791
On Mon, Oct 27, 2008 at 8:44 AM, Can T. Oguz [EMAIL PROTECTED] wrote:
Hi,
I'm receiving an out of
First guess 'Are you doing this in process with a valid graphics
context'
Might help if you provided some basic info such as
How are you scaling the image (code)
What version of osg
What OS
how big is the image
What type of image is it
Graphics card
etc.
have you tried debug the issue?
Hi,
Yes, I've read the previous posts and I have a valid context. I have even
made the calls after the first frame() is executed (to ensure the context)
Source image is 512x217
Dest image is 50x20
OS : Win XP
Image iss JPG, GL_RGB
Card : NVidia 8800 GT
OSG : 2.6.1
and the code is :
for (UINT
Hi Can,
You make no mention where about your call the scaleImage from, there
is chance that you think you are calling it from a thread with the
graphics context but don't. Without more info about your usage there
isn't anyone else can say. Please remember the OSG is multi-threaded,
and by
Hi,
I'm running OSG in single threaded mode and making the calls right after the
context setup code, but if you think that the scaling operation needs to be
done within the OSG's inner threads; then there's no chance that I could use
this function. If you suggest an alternative, I'll follow.
Hi Robert,
For my usage of computeIntersections, as I said, I put the test scene into
the osgpick example. From there it is quite clear that the picking results
do not return what I believe most people will expect for that scene.
I was aware that the computeIntersections method is a wrapper
Hi,
I am using these two methods: setViewMatrixAsLookAt(eye, center, up)
and getViewMatrixAsLookAt(eye, center, up) with the viewer's camera in
this order and WITHOUT manipulating the camera elsewhere in my code. I don't
have much experience with OSG but isn't the last method supposed to
Hi Can,
The osgViewer::Viewer by default now releases the context after
frame() even in single threaded - this is required to handle users
calling multiple viewers from one frame loop. In
include/osgViewer/ViewerBase you'll find the method:
/** Hint to tell the renderingTraversals()
The center isn't stored in the matrix, of course. Once the matrix is
constructed, the center could be any random point along the view direction
vector. You'll need to specify an eye distance, or scale the value yourself.
-Paul
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Hi Renan,
The answer to your problem can be found in the implementation of the
getViewMatrixAsLookAt(), note the last optional parameter.
/** Get to the position and orientation of a modelview matrix,
using the same convention as gluLookAt. */
void
Hi Ralph,
I am using the last versions from svn. Perhaps this warning from
gdalinfo gives a hint on what is wrong with this data?
gdalinfo volcanes.tif
Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts
field, ignoring and calculating from imagelength
because otherwise it
Hi John,
On Mon, Oct 27, 2008 at 4:07 PM, John Cummings [EMAIL PROTECTED] wrote:
In the process of finding a small example, I've realized that indeed the
reference document is not clear at for this feature.
The reference documents say nothing about texture wrap modes at all.
Given that this is
Hi Alejandro,
There is no coordinate systeml information for VPB to go on, and empty
string for the coordinate system is not sufficient for determining the
coordinate system, the origin and pixel size info aren't sufficient
on their own.
Robert.
On Mon, Oct 27, 2008 at 4:32 PM, Alejandro
Hi Robert and Umit,
As probably you already read it, my data is georeferenced but has no
projection info (plain latitude, l,ongitude). Using plain osgdem
produces a wrong 1 dimension field (a line).
osgdem -d volcanes.tif -l 8 -v 1.0 -o kk
I have to give some approximated --xx and --yy data
Hi Robert:
Yes but they are perfectly georeferenced. What shoud I do?
--geocentric is enough?
-- A.
On Mon, Oct 27, 2008 at 10:38 AM, Robert Osfield
[EMAIL PROTECTED] wrote:
Hi Alejandro,
There is no coordinate systeml information for VPB to go on, and empty
string for the coordinate system
Hi Alejandro,
Your data *is* the problem, please add the coordinate system info.
Using the --xx etc options really is not a good solution going
forward. Use properly set up data and things will work fine. Please
go check out the gdal website for info on how to set up your data.
As for VPB
Thanks, Paul and Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Hello all,
I've a simply question about the NodeKit osgSim. Can everybody explain me
when it's commendable to use. What is the benefit? I used never before.
Cheers,
Martin
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi All,
I'm just prepping for the OpenSceneGraph-2.7.4 dev release, so am once
again looking for help in testing!
There have been lots of bug and build fixes checked in since 2.7.3,
and feature refinements but as always this might come with their own
regressions, so please do a check out of
On Mon, Oct 27, 2008 at 5:18 PM, Chris Denham [EMAIL PROTECTED] wrote:
Thanks Robert,
I hadn't anticipated you checking also checking in the modified osgpick
example.
This may not be quite what you might intend, since the default scene used to
be fountain.osg, but now has my rather
Now that you have explained to me how it works, maybe you could give me an
idea on how to solve a small problem I have.
In my application, the user can move the camera freely (all directions and
eye positions), but when the camera's direction is close to a given one, it
snaps into that given
Hi Renan,
You'll need to store basic parameters that you use to compute your
view matrix, for instance the eye point, center, up, or whatever is
most suitable for the type of camera manipulation you wish to
undertake. For instance the osgGA CameraManipulator's all have there
own camera model
Folks,
Can primitivesets be shared between geometrys similarly to vertexes,
colors, and texcoords?
Brian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Ditto Robert's comments, with the following info:
setViewMatrixAsLookAt doesn't do anything magical, it just fills in the
matrix with four vectors to create the orthonormal basis and origin of a new
coordinate system. You already have the necessary data to compute this
matrix yourself. See the
Hi Alejandro
You can use gdalwarp to (stamp) the projection information into you data.
try using something similar to the following:
//call gdalwarp to project my data to wgs84
//This will create a virtual raster (vrt) which does not copy the data of
the original raster
//but creates a sort of
Not a question so much as a note for the archives.
If you want ViewerQOSG to be able to handle signals it must have a Q_OBJECT
definition.
In order to do this the viewerQT example must swap the order of the definition
to class ViewerQOSG : public QOSGWidget, public osgViewer::Viewer
The QT moc
Hi Ralph,
It works, thank you very much! :)
-- A.
On Mon, Oct 27, 2008 at 1:57 PM, Ralf Stokholm [EMAIL PROTECTED] wrote:
Hi Alejandro
You can use gdalwarp to (stamp) the projection information into you data.
try using something similar to the following:
//call gdalwarp to project my
FYI, here is the link to the discussion on the Ac3D forum:
http://www.inivis.com/forum/showthread.php?t=5090
It seems to be headed in the same direction as Robert's comments regarding
keeping track of the UV ranges.
-John
-- Original Message --
Subject: Re: [osg-users] Call
On Mon, Oct 27, 2008 at 10:42 PM, John Cummings [EMAIL PROTECTED] wrote:
FYI, here is the link to the discussion on the Ac3D forum:
http://www.inivis.com/forum/showthread.php?t=5090
It seems to be headed in the same direction as Robert's comments regarding
keeping track of the UV ranges.
The TrackballManipulator does not support a zoom function. Rather, the right
mouse button pans the Camera along the view direction vector. This is a
different effect from zoom, which is a change to the field of view without
changing the Camera position. With an orthographic Projection matrix,
Thank you Paul. That does help me out a lot. I have one follow-up
question, however. It is not clear to me how to fashion a manipulator
so that it automatically modifies the projection matrix. I noticed that
osgViewer::Viewer will automatically ask its camera manipulator for the
model view
hi all,
It seems that there is a problem with
CullVisitor::updateCalculatedNearFar,I have the code like this:
osgViewer::Viewer viewer;
class MCallBack : public osg::NodeCallback
{
public:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
49 matches
Mail list logo
