can someone please explain to me what exactly ViewPort is? If I look into the Application.java file, I can see two kind of viewports. viewPort and guiViewPort. Due to the fact that the gui is always drawn over the 3D scene, I assume the viewport to be a kind of “layer”. However, in the multicanvas tutorial, viewports are used to create multiview 3D scenes. I understand that a camera is always attached to a viewport but do not really understand the overall idea behind the difference of guiViewPort and viewport.
Thanks for help.
Well…reading your question, i guess you pretty much understood what is a viewport…there is not really much more about it.
The thing to know is that 2 viewports can contain different scenes. For example the main viewport contains the scene that will be rendered to the screen, and you can have another viewport containing a scene that will be rendered to a texture used in the main scene.
For the water effect we use 2 pre-viewports (rendered before the main viewport) to render the reflexion and refraction map to apply on a water plane.
Those viewports can have different size than the main viewport, and different settings.
Think of it like a point of view on a scene that will be rendered separately.
OK, thanks you. My next question would be following. Would you agree that I can “kill” the “main viewport” initialised by Application.java and add my own viewport right from the scratch? Would you think that this effects anything?
I don’t really have to agree, you can do anything you want :p.
But yeah, it’s safe if it’s what you mean.
But…just for curiosity, what do you want to do?
I am building a JME Editor on top of Netbeans like your JMonkeyPlatform project. I start my platform. Everything is represented as a node of course. My first node is an “Application” node which holds the application instance. Of course, I want the user to add multiple cameras and therefore multiple viewports. If there is already a viewport available (Application.java file) I can not set the camera, because there is no setCamera method. The camera object itself must also be an instance of the camera node representing the camera. the problem is, that I can not take the camera object from JME because my whole tree structure is saved as an xml tree. So, if I load the xml tree, and therefore the complete scene, my camera must be instantiated from my code, not from JME Application.java. It would be ugly coding to let the camera object and therefore the viewport object left. The problem is that you want the user to get such an easy code, that you already implemented all necessary objects for viewing a scene. Although this is very clever for beginners, it is not straight forward for experts. All people must extend at least the Application.java class and therefore already get a camera and viewport object.
Nevertheless, JME 3.0 is better than JME 2.0. I forgive all developers that they have started a new engine right from the scratch although my editor for JME 2.0 has nearly been finished.
Thanks for fast help.
The problem is that you want the user to get such an easy code, that you already implemented all necessary objects for viewing a scene. Although this is very clever for beginners, it is not straight forward for experts.
You're right about that, we want beginners to quickly be able to render a 3D scene without too many work. But we also want that experts can do what ever they want without being stuck, and if the process it easy for them too...it's better :p
That's why this kind of feed back is important for us.
So would a setCamera method on the viewport help you?
About your editor, why not contributing on JMP instead of going for your own editor? I mean you surely have good ideas and everyone could benefit of them.
His approach sounds more like a “game editor”, something that is planned as a plugin for jMP later. From what he said, he instantiates a scene from some xml description file rather than loading a jME scenegraph directly. And from what he said earlier on the forum, it was planned to support multiple 3d engines. So its kinda the opposite approach than jMP: going from what you’d might want to do to create a game instead of “externalizing” the special functions of the game engine like jMP.
jMP will probably use the (WIP) game entity system of jME3 in companion with the newly added “user objects” in the jME3 Spatials to create a similar environment with specialized plugins to create FPS-style games or MMO-like ones. Of course any contributions on that side are very welcome but I can also understand that one might want to implement exactly the approach one has in mind w/o caring too much about engine specific stuff.
the problem is that I want to build a very complex scientific editor engine on netbeans platform. This scientific editor will be able not only to map scientific properties of material, crystals, molecules, atoms etc. but should also be able to visualize them. I am already working for more than 4 years on the background.
The problem is that I use very individual files in a netbeans module which are the basis for all other modules. Nearly all classes depend on these base classes.
Normen is absolutely right. My editor is based on loadeing my own “specific xml file”. However, this is absolutely no problem. In future releases I’ll try to perform 1:1 mapping between my files and the JME binaries. I would like to show you a release if I have a “stable” version (whatever stable means in terms of software).
However, I appreciate your work very much. I could never do everything alone. I like JME 3.0 much more than JME 2.0. I’ll come up with many questions in future.
oh ok, sounds like a very cool project.
if I look at the source code, I can figure out, that you do not have to register a create ViewPort. So, the call
seems to be enough. If I call this method, the returned viewPort is automatically added to the renderQueue.
Is this correct?
Is a call to
also enough to totally remove the viewPort and make it disabled so that it does not take any resources?
@Equilibrium: Yes this is correct