GeometryBatchFactory picking problem

don’t know what it is,

i’m now getting that same error again after a clean install - everytime i run jme- i’m wondering if it’s the cause





java.lang.IllegalArgumentException

at com.jme3.bounding.BoundingBox.setYExtent(BoundingBox.java:902)

at com.jme3.renderer.Camera.setGuiBounding(Camera.java:1105)

at com.jme3.renderer.Camera.onViewPortChange(Camera.java:1093)

at com.jme3.renderer.Camera.resize(Camera.java:385)

at com.jme3.renderer.RenderManager.notifyReshape(RenderManager.java:231)

at com.jme3.app.Application.reshape(Application.java:354)

at com.jme3.system.lwjgl.LwjglCanvas.runLoop(LwjglCanvas.java:188)

at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:206)

[catch] at java.lang.Thread.run(Thread.java:680)

EDIT: ignore this, it’s only affecting WireBox which has no faces and it’s not supposedly collidable & it doesn’t pertain to this topic


after rereading some of your previous posts I've decided to say the following:
it's probably unrelated to what you're using but related to intersection misses, but I've noticed some weird collisions with WireBox only, while it works ok with Box (this is unrelated to the r7291 fix though), I ain't sure if the weird collision detection happens only for WireBox or it extends to something more (as if it's not some bug in WireBox but in the collision detection system). I can't explain the weirdness yet because I don't fully understand it, I just know it's different than if it were a Box instead of WireBox, and it seems to go through the WireBox at some places, like see the screen in this post where it shows the purple marker hitting the red arrow thus going through the purple WireBox:
http://hub.jmonkeyengine.org/groups/development-discussion-jme3/forum/topic/wirebox-collisions-detected-on-the-inside-instead-of-the-outside-like-for-box-jme3-r7293/#post-125756
(probably should not have posted this, but to me it seemed related, to your prev. posts)

I’ve no idea! I’m having a nightmare with JME at the minute.

regarding intersections, I only had a problem with that after geometrybatchfactory.optmize - otherwise no problems.



i’ve started a separate thread regarding the ‘error in scene’ exception.



I’ll come back to this thread regarding my local to world space coding if I get my other problems fixed.

okay for now i’ve just reverted to a clean install without installing any updates - at least it works.

after finally coding my own geometry batching function- i’m getting exactly the same problem - some faces need rotated 360 to be detected by collisions, and the collisions still by pass random points on the geometry…



my code simply adds up all the vertex/index/tex coords into a single mesh, and uses localtoworld to reposition transformations, but sill the same problems.



i appreciate jme is in alpha, but i seem to spend a lot of time trying to get around these kinds of issues.



i’m actually just looking at moving over to other game engines, including ogre and unity 3d. if anyone can recommend one that would be great.

Use Ogre3D when you don’t mind being in “C++ land of pain”, its at least open source and you can give input / help fixing bugs :P. Unity is more or less a one trick pony and it costs a small fortune. No other freely available engine has the feature set of jME3 (shaders, physics, full source) and none of them such a unified API consistently written in one language. So gl :wink:

Edit: Also, you have been told problems were fixed in latest svn, why are you switching back to alpha-4, the “illegal state” bug has been fixed too. A nightly version can break, thats quite normal, that is why there is a stable version. And that an alpha-software might have bugs, well you said it, thats normal too.

1 Like
xp61 said:
don't know what it is,
i'm now getting that same error again after a clean install - everytime i run jme- i'm wondering if it's the cause
java.lang.IllegalArgumentException
at com.jme3.bounding.BoundingBox.setYExtent(BoundingBox.java:902)
at com.jme3.renderer.Camera.setGuiBounding(Camera.java:1105)
at com.jme3.renderer.Camera.onViewPortChange(Camera.java:1093)
at com.jme3.renderer.Camera.resize(Camera.java:385)
at com.jme3.renderer.RenderManager.notifyReshape(RenderManager.java:231)
at com.jme3.app.Application.reshape(Application.java:354)
at com.jme3.system.lwjgl.LwjglCanvas.runLoop(LwjglCanvas.java:188)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:206)
[catch] at java.lang.Thread.run(Thread.java:680)

this one was fixed recently(probably after you posted) in this revision here
xp61 said:
okay for now i've just reverted to a clean install without installing any updates - at least it works.

Maybe you should update to latest from svn[again?] (or something similar ie. nightly builds? though I don't know if they are up to date(maybe need to wait max 1 day?), svn would be preferable) because at least 1 bug (localToWorld that momoko_fan said above in a post) but probably 1+2 could affect you (r7298, r7263 + r7296,r7291), otherwise it could just be something new (new bug that is), it would be preferred (by me at least) if you could write a small testcase(new program) that would show your issue with the needed rotation on Z to fix that intersection (as you said), even if(and especially so) it's rather simple (ie. no textures)
By the way, did you ever used negative scales? ie. setLocalScale(-3,4,-6); [two negative params] appear to cause missed collisions (for corners of a Box, at least for a Box and a Ray from certain Ray angles) - this might not apply to you, of course

EDIT: I just noticed that this fix (done 5 hours ago):
https://code.google.com/p/jmonkeyengine/source/detail?r=7301
[which has something to do with Bone and Skeleton, using same temp vars (thus overwriting could occur?)]
is not part of the latest nightly build which is this: jME3_2011-04-24.zip
however, this fix and all prior (at least) are part of that build;
1 Like
normen said:
Use Ogre3D when you don't mind being in "C++ land of pain", its at least open source and you can give input / help fixing bugs :P. Unity is more or less a one trick pony and it costs a small fortune. No other freely available engine has the feature set of jME3 (shaders, physics, full source) and none of them such a unified API consistently written in one language. So gl ;)
Edit: Also, you have been told problems were fixed in latest svn, why are you switching back to alpha-4, the "illegal state" bug has been fixed too. A nightly version can break, thats quite normal, that is why there is a stable version. And that an alpha-software might have bugs, well you said it, thats normal too.


thanks normen - yes i agree c++ is hell - i done iphone development for a year :(

i rolled back to alpha 4 because my whole project stopped working - my geometry completely disappeared and couldn't figure it out - i think it might be to do with transforms working differently somehow. i'll give it another try and update the plugins/build again.
xp61 said:
thanks normen - yes i agree c++ is hell - i done iphone development for a year :(

Huh? Thats Objective-C and C mostly, only CoreAudio uses C++ really.. Obj-C is cool, almost like java as soon as you get the square-bracket-x-ray-eyes. And C is golden, the mother of all proper languages ;)
cyuczieekc said:
this one was fixed recently(probably after you posted) in this revision here



Maybe you should update to latest from svn[again?] (or something similar ie. nightly builds? though I don't know if they are up to date(maybe need to wait max 1 day?), svn would be preferable) because at least 1 bug (localToWorld that momoko_fan said above in a post) but probably 1+2 could affect you (r7298, r7263 + r7296,r7291), otherwise it could just be something new (new bug that is), it would be preferred (by me at least) if you could write a small testcase(new program) that would show your issue with the needed rotation on Z to fix that intersection (as you said), even if(and especially so) it's rather simple (ie. no textures)

By the way, did you ever used negative scales? ie. setLocalScale(-3,4,-6); [two negative params] appear to cause missed collisions (for corners of a Box, at least for a Box and a Ray from certain Ray angles) - this might not apply to you, of course


yes i'll try updating svn again..

p.s. how do i roll back to individual versions of patches like r7298 for example, sorry i'm still new to java development.
i haven't been using negative scales,
if i get stuck again - i'll put together a testcase, thanks..
1 Like

Just enable the nightly update center and update to the latest version, all mentioned bugs are fixed in the latest nightly.

1 Like
normen said:
Huh? Thats Objective-C and C mostly, only CoreAudio uses C++ really.. Obj-C is cool, almost like java as soon as you get the square-bracket-x-ray-eyes. And C is golden, the mother of all proper languages ;)


i still hated it!
extremely long winded variable names and declaration/definition syntax - and oh the hell of memory allocation/management,
but yes, at least it's obj-c and familiar from a java point of view.
1 Like
xp61 said:
extremely long winded variable names and declaration/definition syntax - and oh the hell of memory allocation/management

Yeah, long names is what you get when everything shares one namespace.. The memory allocation and deallocation is actually quite easy given that you always have a RunLoop. With autorelease you don't even need to think about it in many situations and the debugger makes finding memory leaks super-convenient. Still, I like java better too ;)
1 Like
xp61 said:
yes i'll try updating svn again..

p.s. how do i roll back to individual versions of patches like r7298 for example, sorry i'm still new to java development.
i haven't been using negative scales,
if i get stuck again - i'll put together a testcase, thanks..


I don't actually know how you could do that(I'm rather inexperienced really) to roll back only a certain revision while you're at a future revision, while still maintaining the future revision (sort of like pulling out a certain revision from the transaction queue, erm nevermind this)
When I said that(with undo-ing certain fix), in a previous post, I was referring to r7291(and I meant to do it manually, by seeing what was changed and changing it back by typing or rather commenting and uncommenting the code) which it then made sense to roll back because it made worldToLocal gave bad results(with that fix), but now worldToLocal was fixed in r7296 (both fixes are included in latest build, as normen said), therefore I do not recommend rolling back those two (they are both fixing issues that appear only when using non-unform scales).

Whenever&if you put a testcase I'd love to "dig in" ;) though I do hope the fixes make it work now..
cyuczieekc said:
I don't actually know how you could do that(I'm rather inexperienced really) to roll back only a certain revision while you're at a future revision, while still maintaining the future revision (sort of like pulling out a certain revision from the transaction queue, erm nevermind this)
When I said that(with undo-ing certain fix), in a previous post, I was referring to r7291(and I meant to do it manually, by seeing what was changed and changing it back by typing or rather commenting and uncommenting the code) which it then made sense to roll back because it made worldToLocal gave bad results(with that fix), but now worldToLocal was fixed in r7296 (both fixes are included in latest build, as normen said), therefore I do not recommend rolling back those two (they are both fixing issues that appear only when using non-unform scales).

Whenever&if you put a testcase I'd love to "dig in" ;) though I do hope the fixes make it work now..


yeah i'm going to update everything again, and try and get my scene working before looking at the collision problem again.. here goes..

Theres a manual entry on using your own checkout of jME3 for your projects:

use_own_jme :: jMonkeyEngine Docs

When you have a separate checkout for jME3 its easy to roll back to a specific revision using the built-in svn tools.



P.S.: @cyuczieekc Are you spamming the thumbs up? :wink:

1 Like
normen said:
Theres a manual entry on using your own checkout of jME3 for your projects:
https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:use_own_jme
When you have a separate checkout for jME3 its easy to roll back to a specific revision using the built-in svn tools.

P.S.: @cyuczieekc Are you spamming the thumbs up? ;)


that looks useful thank you.

@normen: I are, but I’d like to believe I do it only for posts that are helpful and/or I agree with xD

Happily,

me monkey :smiley:


since this post is useless for this topic(just replying to normen's PS xD), in order to make it less useless... allow me to spam this link to a different topic (somewhat related to this current topic):
http://hub.jmonkeyengine.org/groups/general-2/forum/topic/how-to-detect-collisions-after-geometrybatchfactory-optimize-jme3-r7245/

Heh, you can thumbs up whatever you like :slight_smile: Just wanted to know because theres a definite rise in thumbs up in the last few days :wink:

1 Like

@normen:

====

I wonder what’s @xp61 doing, I really am :slight_smile: I’m kind of bidding my time waiting… (not to imply any obligations though)