I finally tracked down the problem with menu’s not showing up in the desired location. I was flipping the Y coord over and over and over at the screen level. This has been fixed. Sorry for the long wait. It took me a while to find the problem.
Now… the issue I need help with from anyone in core dev:
Elements in this library are nodes. When a node is added to another and the z-order is pushed forward slightly (this is at runtime in the gui node btw), the visual render of the scene is completely correct, however… if you cast a ray into the scene, the order in which the results comes back is not correct. If I remove the absolute parent node and reattach it to the guiNode, then both the visual render and the ray cast are proper.
I have been able to verify the ray cast issue by adding a window… dynamically adding a button at runtime. The button shows above the window however is not clickable. If you resize the window so it does not cover the button, the button is seen by the ray cast and works as expected. If you resize the window so it surrounds the button half way… half the button is clickable… the other half is seen is the results of the ray cast as being behind the window.
I completely understand if you don’t feel this is critical or even requires a patch, because I don’t know if this issue carries over into other circumstances. I just wanted someone to be aware of it’s existence.
@t0neg0d said:
Added at run-time: End-user does something that causes a new Element to be added to the scenegraph. (like clicks a button, moves a slider, etc)
But if you add them otherwise then they work fine?
Still sounds like the problem is somewhere else. I can’t think of anything in the JME-realm that would care when it was added unless update management is wonky.
Can you produce a simple test case that exhibits the issue?
@pspeed said:
But if you add them otherwise then they work fine?
Still sounds like the problem is somewhere else. I can’t think of anything in the JME-realm that would care when it was added unless update management is wonky.
Can you produce a simple test case that exhibits the issue?
Sorry for the delay on this… my father is in the hospital and dying =( This helps take my mind off it, but my attention gets pulled in other direction.
I’m trying to figure out a way to show this not using the library that won’t take a while to put together. I’ll post something as soon as I have it.
@t0neg0d said:
Sorry for the delay on this... my father is in the hospital and dying =( This helps take my mind off it, but my attention gets pulled in other direction.
Sorry to hear it. My wife goes in for brain surgery again soon and I’m using this as a distraction, also.
@pspeed said:
Sorry to hear it. My wife goes in for brain surgery again soon and I'm using this as a distraction, also.
Paul… I am so sorry to hear about your wife. That situation is far worse.
But! I could kiss you right now. Thank you for making me go through the effort of putting together a test case! It showed me just where MY problem was!!! You’re brilliant!
EDIT: I should explain. This code went together so fast, I failed to take out one line of test code that had this nasty side effect in the ray casting. Sooooo bizarre that it would only show up in this one circumstance in this very particular way.
@t0neg0d said:
Paul... I am so sorry to hear about your wife. That situation is far worse.
But! I could kiss you right now. Thank you for making me go through the effort of putting together a test case! It showed me just where MY problem was!!! You’re brilliant!
EDIT: I should explain. This code went together so fast, I failed to take out one line of test code that had this nasty side effect in the ray casting. Sooooo bizarre that it would only show up in this one circumstance in this very particular way.
Glad you found it. That’s one of the reasons we ask for a test case… seems like 99% of the time it helps the original person find their problem.