Hi!

jPCT steht wohl für "Java Perspective Correct Texturemapping".

Siehe: http://www.jpct.net/forum2/index.php?topic=406.0

Guten Rutsch!

Ok, I found a solution.
For those interested, it looks like this:

// class members:
BufferedImage photoImage;
FrameBuffer photoBuffer;
File photoFile;

...
// within some method:
// you might have to store the original camera here <--

photoBuffer.clear();
Camera photoCamera = new Camera();
photoCamera.setPosition(_from);
photoCamera.lookAt(_target);

world.setCameraTo(photoCamera);
world.renderScene(photoBuffer);
world.draw(photoBuffer);
photoBuffer.update();
photoBuffer.display(photoImage.getGraphics());

world.setCameraTo(cam.getJpctCamera()); // restore prev. cam

try{
ImageIO.write(photoImage, "png", photoFile);
}
catch (IOException ex){
...
}

As you can see, I have a dedicated (Software-) FrameBuffer for the purpose. I render into a BufferedImage object by getting its Graphics stuff.
There is no render-to-texture involved. The camera switching is a bit ugly but seems to work.

I'm not sure about the performance. But since it is only invoke once in a while I don't care so much.

Have fun!

Hi!

I'm looking for a way to to take some kind of "screenshots". There are however some differences to actual screenshots:
Imagine to have multiple cameras in a world. What I want to to next is to save exactly what they're seeing at one exact point in time - preferably as image.
I had a look at the Camera and Projector classes, but I failed to find anything similar. Before I start implementing this on my own,
I want to make sure that:

• I haven't missed something
• I get some input on how to approach this first

Thank you in advance!

No idea if it's related, but lwjgl changed the default glClearColor's alpha in v2.7:
http://lwjgl.org/forum/index.php?topic=3741

Hi!

I had a short look at your picture, but without knowing how it should look, it's hard to understand what's going on.
Perhaps you could elaborate more on what is not shown.

QuoteI mean is there a "visible" point in space that the model is hitting and nothing gets rendered beyond that point?

Sure. It's called view frustum. The near & far plane might concern you.

Maybe your model has errors? You could try to invert it. As said, it's hard to tell, what's going on.

Have a look at the "Config" class for the clipping things.
Inverting the model is done on the object.

Hope it helps.

Yeah, I noticed it was you!
That there's no solution in sight is sad.
I will go with instructions for X11. This not perfect, but at least I know what to blame.

More infos:

• 2 Monitore connected to 2x GeForce 9500 GT
• Linux: 2.6.32-28-generic
• Ubuntu SMP x86_64
• NVIDIA Driver Version: 195.36.24

jPCT prints:

Current mode:3200 x 1200 x 24 @50Hz
Driver is: unknown OpenGL driver on NVIDIA Corporation / GeForce 9500 GT/PCI/SSE2


Seems to be quite up-to-date. Not sure about the Nvidia-driver though.

[edit:] also see: http://lwjgl.org/forum/index.php?topic=2715.0 (seems I'm not the first one)
[edit2:] translated to english...

Hi everyone!

I'm currently trying to nail down a problem. So this is more a poll than a question... If you already know the answer though, don't hesitate!
Here it goes:

Problem:
The Driver reports to support only a single resolution. This is queried by:
FrameBuffer.getVideoModes(IRenderer.RENDERER_OPENGL);

Infos:
Resolution reported: 3000x1200
OS: Some Linux

The problem is not reproducible here. I requested more details and will post them here.
My guess (->resolution) is, that a dual monitor setup is used and jPCT/LWJGL has problems with it.
Can anyone using a multi-monitor-setup confirm/dismiss this idea? I, unfortunately still work on a
single headed system :-(

Thanks for your time!
   Roland

PS: Note my clearly superior skill in using the bold-tag ;-)

I'm not sure about the speed up. I would have to convert my data types first and stuff them into arrays. I think I would just change where the processing is done.
Right now, I'm happy it works this way. My models are also rather primitive, so I currently don't have need.

But thanks for the hint, I'll keep it mind for the future :-)

Roland

Got it. So I think the st=uv equation is correct. At least, when you use Wings3d ;-)
What I got was a combination of two problems:

1. My Triangle-Class only stored references to the vertices. This caused the loader to override some uv-coordinates. Clearly my fault. Debugging is such a joy 

2. As Egon suggested, the exporter seems to use a different coordinate system for the uv-stuff. Using (1-v) does the trick.

So Problem solved, Thanks a lot!

Roland

Ok, I just hand-checked the VRML. It makes complete sense, if it makes use of UV-coordinates. The Internet, by the way, has multiple opinions on uv/st coordinates.
I will just assume, that they are indeed equal and that I messed something up elsewhere.

I let you know, if I stumble upon something.

Roland

QuoteI was under the impression that st is just another word for uv.

That's what I thought as well. I looked around and found this:
http://www.vrmlsite.com/aug96/spotlight/textures/textures.html

QuoteTry to add something 1-s and/or 1-t instead.

Tried it. (1-t) seems to be a small improvement. But I don't think that is the problem.

http://img146.imageshack.us/i/dice.png/
What you see should look like a dice... A single number on each side.
With (1-t), at least two sides seem correct.

Thank you for your time!
Roland

Hi!

I'm currently trying to bring some colors to my virtual worlds by adding textures. But I'm somewhat stuck.
I created a model & texture according to http://www.code5.ch/meckardt/tutorials/wings_textur.html (German)
and exported it as VRML. The exported stuff seems reasonable, even though I didn't check it manually.

#VRML V2.0 utf8
#Exported from Wings 3D 1.2
DEF cube1 Transform {
  children [
    Shape {
      appearance Appearance {
        material DEF cube1_auv Material {
          diffuseColor 1.0 1.0 1.0
          emissiveColor 0.0 0.0 0.0
          specularColor 1.0 1.0 1.0
          ambientIntensity 1.0
          transparency 0.0
          shininess 1.0
        }
        texture ImageTexture { url "PATH/TO/TEXTURE" }
      }
      geometry IndexedFaceSet {
        coord Coordinate { point [
          -3.032000000000004 -3.032000000000004 3.032000000000004,
          -3.032000000000004 3.032000000000004 3.032000000000004,
          3.032000000000004 3.032000000000004 3.032000000000004,
          3.032000000000004 -3.032000000000004 3.032000000000004,
          -3.032000000000004 -3.032000000000004 -3.032000000000004,
          -3.032000000000004 3.032000000000004 -3.032000000000004,
          3.032000000000004 3.032000000000004 -3.032000000000004,
          3.032000000000004 -3.032000000000004 -3.032000000000004 ] }
        coordIndex [
          0, 1, 4, -1,
          0, 3, 1, -1,
          0, 4, 3, -1,
          1, 2, 6, -1,
          1, 3, 2, -1,
          1, 5, 4, -1,
          1, 6, 5, -1,
          2, 3, 6, -1,
          3, 4, 7, -1,
          3, 7, 6, -1,
          4, 5, 6, -1,
          4, 6, 7, -1 ]
        texCoord TextureCoordinate { point [
          0.0 0.5540970937771938,
          0.0 1.0,
          2.7755575615628914e-17 0.7387961250362586,
          1.1102230246251565e-16 0.18469903125906445,
          0.18469903125906464 0.36939806251812923,
          0.18469903125906464 0.7387961250362585,
          0.18469903125906495 0.0,
          0.2612038749637414 1.0,
          0.2612038749637415 0.7387961250362587,
          0.36939806251812923 0.554097093777194,
          0.3693980625181294 0.1846990312590646,
          0.5540970937771938 0.7387961250362587,
          0.5540970937771941 5.551115123125783e-17,
          0.5540970937771941 0.36939806251812934,
          0.7387961250362585 0.5540970937771941,
          0.7387961250362587 0.18469903125906478 ] }
        texCoordIndex [
          4, 3, 10, -1,
          4, 9, 0, -1,
          4, 10, 9, -1,
          2, 8, 7, -1,
          0, 9, 5, -1,
          3, 6, 10, -1,
          2, 7, 1, -1,
          11, 9, 14, -1,
          9, 10, 13, -1,
          9, 13, 14, -1,
          10, 12, 15, -1,
          10, 15, 13, -1 ]
      }
    }
  ]
}


The VRML-Spec says, that the TextureCoordinate-Node contains st-coordinates. As far as I know, that differs from uv-coordinates by already being "height-aware".
But I'm not really an expert to this... Anyway, the triangles load fine, and i tried just to push the st-coords along with the vertices into jPCT. Obviously without much success.

I also had a short look at TextureInfo that seems to have a different purpose.

I should add, that I have to load the models myself into a different world model. jPCT pulls the vertices (and...) from there.
This is like this:

Object3D o = new Object3D(..);
o.addTriangle( t.vertices[0], (float)t.vertices[0].u, (float)t.vertices[0].v,
      t.vertices[1], (float)t.vertices[1].u, (float)t.vertices[1].v,
      t.vertices[2], (float)t.vertices[2].u, (float)t.vertices[2].v);


Any help/hint would be great!

Roland

PS: I tried to attach a screenshot, but I failed... hard to use these boards ;-)

After digging  a bit around I found the following:

http://lwjgl.org/forum/index.php/topic,2350.0.html

and more interesting:
http://jogamp.762907.n3.nabble.com/SIGSEGV-when-closing-JOGL-applications-td895912.html

Post by Sven Gothel:

QuoteSo, we decided to 'ignore' this SEGV thingy until further investigation,
however, it has something to do with X11 and multithreading.

We use 'XInitThreads()' to setup X11 multithreading support
and it seems that the [J]AWT implementation in the JVM calls
X11 functions before and after JOGL runs.

The lack of calling 'XInitThreads()' in the JVM/JRE (when using AWT)
is already identified as a huge pain and a workaround for this
does not seem to be a good idea at all(*).

The best solution would be to convince Oracle/OpenJDK to issue
the XInitThread() call ASAP (before any other X11 call),
and to revisit some _global_ AWT locks, since they are probably no more necessary.
This would allow true inter-component multithreading with X11
without the need of a global AWT toolkit lock and hence
a fluent X11 workflow where threads won't disturb each other anymore.

BTW .. without XInitThreads() and with XLockDisplay
it was not possible with the NV driver to manage lifecycle operations
(create, makecurrent/release, destroy) in a reliable manner across threads.
Eg:
  thread1: createContext, makeCurrent, some-rendering, release ..
  thread1: stops
  thread2: makeCurrent/release, destroyContext
           -> hangs somewhere, ie makeCurrent, swapBuffer or destroy

So .. we have to think about this, and triage this in more detail.

Multithreading in JOGL is not about using multiple rendering threads
here, but to allow multiple threads to use the same X11 Display connection
for rendering and event dispatching undisturbed, read: non blocking.

For now, all I can say is, don't worry about this message,
it ain't even considered a failure/error with the junit tests.

So this is not a JPCT thing.

Ok, obviously the car & fps example use the software renderer.
The helloworld example however does crash.

run_opengl.sh & run_awtgl.sh produce the same crash. However, run_awtgl.sh seems to have trouble rendering at all.
The created window stays blank.

This indicates, that this is not a problem with my code. Maybe ATI cards are problematic? Unfortunately I don't have
any nvidia cards flying around to test it. Since this doesn't happen when booting windows, it seems to be a problem
either LWJGL or the graphics card driver (or even the Java distribution?).

This officially sucks ;-). I'll watch out for a workaround. But if you have any ideas left, let me know.