I have a Maya/cpp code with an MPxLocator. This locator has an attribute called "Frame", and whenever the frame changes, I have a function that updates that attribute:
MFnDagNode myDagNode(MPxLocatorMObject);
myDagNode.findPlug("Frame").setValue(frame);
However the draw functions is not always started, only sometimes. How can I make the MPxLocator "dirty" when frame attribute is changed ?
Found out that the MPxLocator gets refreshed only if it is visible on screen (or at least the point representing its coordinates).
Related
I have implemented a QGraphicsScene to contain instances of QGraphicsItem of a few different classes implemented by me. What I still don't understand is how the QGraphicsView associated with this scene is updated.
When I call addItem(QGraphicsItem) the scene seems to redraw displaying the newly added items.
When I change properties of my QGraphicsItem instances (e.g. calling setVisible(bool)) it seems that the view is not updated automatically.
I currently call QGraphicsScene::update() without any arguments to draw the new state. this works in most cases, however in some of them it fails ( QGraphicsItem's paint() method is not called. I set a breakpoint there but whether it is reached or not depends on the zoom level in the QGraphicsView. I have to zoom out to a certain level for it to get called again).
It doesn't work when I pass the bounding box of the changed item (scene coordinates) to QGraphicsScene::update(QRect). I can't see objects changing.
Can anybody give me a hint what is the correct way of implementing this? How do I notify the view correctly of changes in certain areas, what does the behaviour depend on. I think there's something wrong with my assumptions about coordinate systems. Thanks a lot for your explanations.
I've been looking through the SFML documentation for making clickable sprites, but so far I haven't found anything.
Do you guys think you could help me out?
There is nothing like sf::ClickableSprite in SFML so far, and probably there will never be. (Current list of classes in SFML)
However, you can obtain this behavior with the sf::Sprite object and the events. The idea is simple - as soon as you get the sf::Mouse::isButtonPressed(sf::Mouse::Left) event, check if the mouse is in the sprite. If it is, perform the action. You can perform another action (maybe undo) when button is released.
There is sf::Sprite::getGlobalBounds() function which returns you the position and the dimensions of the sprite. There's also sf::Mouse::getPosition() function, which returns the current position of the mouse. You can use sprite.getGlobalBounds().contains(mousePos) to check whether the mouse is in the sprite.
If you're using views, you'll need to add the view's position to sf::Mouse::getPosition(window), since it gets the mouse position relative to window coordinates.
(thanks to Chaosed0 for additional notes.)
I am working on a qt-vtk project. We have a line drawing function. where straight lines are created between two mouse click position. But once actor is created it is not visible. I was calling render function just after adding the actor. But it didn't work. But if i do camera->resetview() lines become visible , but entire perspective changes. Where am i doing wrong ?
thanks
Rwik
This may not be relevant to you, but I had this exact same problem (in ActiViz [managed VTK]) and wrangled with it for a week, so I hope this helps someone out there. It turned out to be a problem with the location of the lines we wanted to draw on the canvas; they were too far away from the camera (on the Z axis) to be visible.
For us, we were trying to draw a cross on the viewing area wherever the user clicked. The data points were there, as were the actors and whatnot, but they would only be visible in the scene if you called resetCamera() and thusly changed the camera's configuration.
Initially, I blamed the custom interactor that we had to add to cirvumvent the default interactor's swallowing of MouseUp events (intended behavior). Investigation revealed that this seemed unlikely.
After this I shifted the blame onto the camera under the suspicion that perhaps the reset call was making a call to some kind of update method which I wasn't aware of. I called resetCamera() and then reverted the camera values to what they were initially.
When this was successfully done, it eventuated that the crosses would appear when the camera zoomed out and then disappear again as soon as it was set back, and it was at this point I realized that it was something to do with the scene.
At this point, I checked the methods we were using to retrieve the mouse location in 3D and realized that the z value was enormous and it was placing the points too far away as a byproduct of VTK's methods to convert 2D locations on the control to 3D locations in the scene and vice versa.
So after all that, a very mundane and avoidable mistake that originated from the methods renderer.DisplayToWorld() and WorldToDisplay().
This might not be everyone's problem, but I hope I've spared someone a week of fiddling around with VTK.
I think that's a bit hard to help, without see the code, but have you tried using
ui->qvtkwidget->update();
, where ui is the instance of your class derived from QMainWindow?
I'm using libqglviewer for a project, I read input from a motion capture device through USB and display this as a human in the viewer. I draw the opengl things in the draw() method of the viewer, it works fine. However, when the motion controllers change, I actually get new position values and i draw these in the viewer, BUT i dont see this update until i click on the viewer screen. Is it possible to update the frames in the viewer by itself?
It looks like you just need to post an updateGL right after you get the new position values.
QGLWidget::updateGL()
void QGLWidget::updateGL () [virtual slot]
Updates the widget by calling glDraw().
For painting in 2D the function is called update.
Also, don't call it from inside your draw method (see updateGL in the libQGLViewer documentation).
This note comes from QWidget::paintEvent():
Note: Generally, you should refrain from calling update() or repaint() inside a paintEvent(). For example, calling update() or repaint() on children inside a paintevent() results in undefined behavior; the child may or may not get a paint event.
The same probably applies for QGLViewer.
You can also use repaint, but is isn't recommended (see QWidget::repaint()).
I'm trying to figure out why I've been getting an empty update rectangle when I call InvalidateRect on a transparent window. The idea is that I've drawn something on the window (it gets temporarily switched to have an alpha of 1/255 for the drawing), and then I switch it to full transparent mode (i.e. alpha of 0) in order to interact with the desktop & to be able to move the drawing around the screen on top of the desktop.
When I try to move the drawing, I get its bounding rectangle & use it to call InvalidateRect, as such:
InvalidateRect(m_hTarget, &winRect, FALSE);
I've confirmed that the winRect is indeed correct, and that m_hTarget is the correct window & that its rectangle fully encompasses winRect.
I get into the OnPaint handler in the class corresponding to m_hTarget, which is derived from a CWnd. In there, I create a CPaintDC, but when I try to access the update rectangle (dcPaint.m_ps.rcPaint) it's always empty. This rectangle gets passed to a function that determines if we need to update the screen (by using UpdateLayeredWindow in the case of a transparent window).
If I hard-code a non-empty rectangle in here, the remaining code works correctly & I am able to move the drawing around the screen.
I tried changing the 'FALSE' parameter to 'TRUE' in InvalidateRect, with no effect. I also tried using a standard CDC, and then using BeginPaint/EndPaint method in my OnPaint handler, just to ensure that CPaintDC wasn't doing something odd ... but I got the same results.
The code that I'm using was originally designed for opaque windows. If m_hTarget corresponds to an opaque window, the same set of function calls results in the correct (i.e. non-empty) rectangle being passed to OnPaint. Once the window is layered, though, it doesn't seem to work right.
I think I've figured it out - it's a combination of a limitation of Windows + some odd code in the internal framework I'm using. I have to ignore the empty rectangle & use the entire screen's rectangle instead - it seems to work fine.
Sorry if I wasn't clear enough with my initial question - I'll try to be more precise the next time.