Here is what is strange.
Box starts to move, and when dx reach 80 (or 90), all scene disappears!

Here are 2 images. First one where dx is 40, and second where dx is greater than 80 (you can notice that all other elements are gone - grid and purple line???).

Is it possible to set that coordinate (0,0) on upperLeft corner, and negative y axis to go from up to the bottom.

Also, when canvas size is changed I don't need any transformations on my scene (example: when application is maximized I need Box to be same size as before maximization).

I tried some changes on frustum parameters but I did not succeed.

Is it possible to set that coordinate (0,0) on upperLeft corner, and negative y axis to go from up to the bottom.

I don't think so, the issue is that Java starts at the upper left corner, and openGL starts at the lower left corner...
(although its really simple math to invert the y-axis)

when application is maximized I need Box to be same size as before maximization

This is due to the frustum size change alright, I actually need the same logic in my windowed application also. I have yet to implement it (a LOT of other things to do), but I think you just shrink or expand the viewport with:

I am doing a translation of root node to the (0,0) coordinate, and than scaling with rootNode.setLocalScale(new Vector3f(1, -1, 1)) wich invert y-axis...

Yes, scaling by a -1 is a pure openGL trick that might work; BBBBUUUTTTT there is 2 application layers between you and openGL (jME then lwjgl/jogl), therefore the results of scaling by -1 (for jME at least) are not 'guaranteed'. (although for a simple quad you might be okay)

Yes, scaling by a -1 is a pure openGL trick that might work; BBBBUUUTTTT there is 2 application layers between you and openGL (jME then lwjgl/jogl), therefore the results of scaling by -1 (for jME at least) are not 'guaranteed'. (although for a simple quad you might be okay)

If the transforms are converted into matrices (which any sane renderer would do) then it would result in the following transform matrix:

1 0 0 0
0 -1 0 0
0 0 1 0
0 0 0 1

which is completely valid. It would flip the Y vertices, causing the model to appear upside down. Even if it doesn't use transform matrices, it probably just multiplies the input vertex by the scale, which would have the same result.

(lol, matrix arithmetic takes me back to the smell of chalk dust ;))

I talked to irrisor about a year ago about the same thing and his words were basically the results are not guaranteed…

(a heads up he was kind enough to give me when I started having problems using this exact technique in jME with an actual model and was simply trying to return the favor)

(face winding is a good example of why this approach is not guaranteed, YES it works and for a simple quad there is generally no problem; but for more complex geometry a little more work is generally needed; normals are another issue to consider…)