Independent Textures...

Hi,

How to have independent Textures across multiple windows? All but one window will have just a black white image with display flickering. Within the same window it seems okay.

Tom

I meant to say blank or just solid white... Also, I see some differences in lighting with the exact same graph structure with more than a few windows, I'm wondering if there's some sort of limit that needs to be extended somewhere?

Hi,

Lighting doesn't doesn't seem to work in more than one window... I must be missing a property setting somewhere?

Tom

You have to use a shared context.

How to do that?

Hi,

So for each JFrame there's a JoglSwing/AwtCanvas with a separate CanvasRenderer and DisplaySettings with shareContext set to that canvasRenderer itself? Should ardor3d.useMultipleContexts be true or false? I currently have DisplaySettings.shareContext = null, and useMultipleContexts=true. Please forgive these questions, I can handle the math and geometry, but have only a basic understanding of OpenGL. If this is a problem, what level of effort to have fully independent windows?

Tom

ardor3d.useMultipleContexts = true and DisplaySettings.shareContext != null

Are you sure that there is no example illustrating this use case?

I will play around with the examples and let you know.

Hi,

Very difficult to get the examples to display more than one JFrame. I modified JoglSwingExample to try to create
two windows. Even putting this on the EDT, with the settings above, there are problems. I can only get two windows
if I set useMultipleContext=true and use a non-null shareContext, but they don't work. What should DisplaySettings.shareContext be set to? Are multiple independent windows possible, or will this require substantial new development?

Tom

JoglAwtDesktopExample just works, it uses 3 instances of JoglAwtCanvas. No it won't require any substantial new development as it is one of the most important reason why some developers chose JogAmp's Ardor3D Continuation and it was already working well with the legacy Ardor3D.

However, it's trickier when all canvases have no common parent.

Hi,

We definitely need separate canvases with separate visible parents (Frames). Can this be done? How tricky are we talking?

Tom

Maybe I misunderstood what you wrote. Do you absolutely need to share the textures on all those windows? If it's the case, you'll have to consider numerous limitations:
https://blog.gvnott.com/some-usefull-facts-about-multipul-opengl-contexts/

Otherwise, if you need separate parents but if you don't need to share the textures (i.e you'd need to load a texture on each canvas using it), it will be only a matter of using the frame handlers correctly and the example I quoted might be useful.

Keep in mind that using shared contexts can have a bad impact on performance and stability. What is already supported in JogAmp's Ardor3D Continuation is an acceptable compromise.

JogAmp's Ardor3D Continuation exposes its canvases and windows as JOGL canvases and windows, it helps to use this but there are some drivers that don't support shared contexts. That's why, if I were you, I would be very reluctant to heavily rely on context sharing in a general framework.

I encourage you to use a JDesktopPane like in the example, it's typically designed for this purpose, it's a container. Some CAD softwares use another "trick", they create an always hidden (J)Frame.

Hi,

Window, frame, display, these are can be fairly generic terms. I mean separate, floatable JFrames on a users desktop, each with a unique GLCavnas, and each canvas with unique (one or more) textures (mesh and image), that are unique themselves from the textures in the other JFrames. I don't care about sharing the image data or the mesh points between JFrames, in fact I don't want to. Here's one of our applications, it's not sexy like a game, but leverages texture mapping for fast, efficient rendering of high resolution of satellite remote sensing imagery:



Here there are three separate JFrames on the desktop. We have other applications with full, interactive 3D views, visualizing numerical weather prediction model output for example.

I may have misunderstood an earlier post, but I was assuming this would be okay, and one of the main reasons we decided not to go with JMonkeyEngine.

Are you saying there needs to be some coordination between the FrameHandlers? I have on per Canvas, should there be only one per application which updates the canvases together?

Tom

As you don't care about sharing, JoglAwtDesktopExample is enough and works as is. You can use a single frame handler with several canvases or updaters.

So only one JFrame containing multiple JInternalFrames, or can the JInternalFrames be broken out into separate JFrames themselves? Working this weekend, no fun :(

I'm sure I tested your first suggestion, your second one should work but I wouldn't be 100% affirmative. Don't use one frame handler per canvas except if you really need to do something completely different in terms of life cycle management.

I made a modification of JoglAwtDesktopExample which separates the JinternalFrames into separate floatable JFrames and it works fine. I suppose then that even with multiple canvases spread across multiple JFrames, one thread triggering a single FrameHandler.updateFrame() that all of the canvases reference is the best approach? Does Jogamp Ardor3D handle coordination to the single graphics device? I think my trouble is that I had a separate FrameHandler and runner thread for each individual canvas?

Actually, I don't see the interest of using multiple threads to call FrameHandler.updateFrame() in your case. Why do you mean by "coordination to the single graphics device"? Don't forget that some canvases might have some limitations. GLJPanel has an higher memory footprint than GLCanvas, both need to perform numerous operations on the AWT EDT. Have you tried to use JoglNewtAwtCanvas?

thanks, I will experiment with JoglNewAwtCanvas as well.

Hi,

This thread should probably be renamed "How to have independent JFrames or JInternalFrame". I've attached SSCCE based on Jogamp's Ardor3D example code:

MultiJFrameTest.java
JDesktopTest.java
RotatingCube.java
MyThread.java
MyScene.java

Separate JFrames (MultiJFrameTest) or using JDesktopPane (JDesktopTest) exhibits the problem. The former can be
made to work with a strange hack: the top level Scene needs to have something added to it.

I'm trying to use Jogamp Ardor3D for a workflow that allows users to add new scene elements (or delete them) in one or more frames that won't necessarily be created at the same time after the master FrameHandler and Runner thread have been started.

Does the hack offer a clue how to fix the problem, or perhaps a reliable workaround. The hack is I just put a tiny cube in the top  level scene before canvas is initialized. (It's like it can't be empty or something). My concern is that these hacks often don't work in general, or mysteriously stop working where they had before.

Jogamp Ardor3D is really going to be great step forward for us. You mentioned in this thread a couple of tricks, what kind of development commitment am I looking at to make this work?

Tom