JglTF can not display preview if the primitive type is LINES? #11
Comments
|
Thanks for this hint and the links to the sample models! But I think that the main problem is in the models here. Both are defining the following Obviously,
I manually replaced it with this technique: (Note: This is NOT carefully validated, I just quickly "tried to fix it" - the basics should be correct, but before using this as an official fix or in a PR, it should be reviewed!) The result is then
(I tested it with my current local state, but it should also work with the current release - there haven't been so many relevant changes recently. And BTW: I wanted to upload a new preview release this week, but was busy with other stuff - I'll do an update ASAP). |
|
It is not entirely clear how the model has been created. Obviously, Three.js makes some assumptions or uses several reasonable "defaults" when it does not find the required information in the glTF itself. I also threw the model into the validator at http://github.khronos.org/glTF-Validator/ It emits several errors and warnings. Most of them are related to the fact that it validates against 1.1, but the given model is 1.0. Here, I omitted the errors that are caused by the different version: (With the changes that I mentioned, it still causes errors, but as far as I see, they are all related to the differences between glTF 1.0 and glTF 1.1) |
|
I'm sorry, I can not judge whether the new glTF file is okay, so can you confirm the following? |
|
I tried to display snowflake and snowflakes with the latest version of JglTF. I found two worrisome things.
|
|
Regarding the snowflake: That's a minor typo in the shader, I added a mrdoob/three.js#10539 (comment) for that. Regarding the fact that it cannot be rendered with JOGL: That's exactly the reason why I opened KhronosGroup/glTF#587 a while ago. I'll open another issue here for that in a few minutes. |
|
Other models (e.g. the Box or Cesium Man) will be displayed without problems with JOGL. It seems that it is not displayed in JOGL only in the snowflakes model. |
|
JWJGL + Reset camera JWJGL + Fit camera JOGL + Reset camera JOGL + Fit camera In the case of JOGL, I feel that I do not displayed it when I move the camera away. |
|
I changed the angle and it was displayed a little. JOGL JWJGL |
|
First of all: Sorry, I might have mixed up the two points here: The "snowflakes" (plural) example does not cause any error messages, but only fails to display properly with JOGL, right? And why does it not render properly in JOGL? Yes, that's odd: Except for certain "infrastructure" things (like the aforementioned GL profiles), LWJGL and JOGL should basically be the same. They are both very thin layers around OpenGL, and with my viewer, I only added a very thin layer around both of them, but the actual GL commands are the same for both! But from the symptoms that you described in the last comment, one can already guess what's wrong: By default, the far clipping plane is set to 10000.0. And the snowflakes are so large that they have to be moved ~10000.0 away from the eye to be completely visible. (I do not know why it behaves differently for JOGL and for LWJGL, but when you use LWJGL, then use "fit camera", and zoom out a bit more, the snowflakes should also disappear) Of course, the value of 10000.0 is completely arbitrary and is not applicable to general scenes. I think that finding a solution for this may, in fact, be rather tricky, but I consider this as part of #7 |
That's right.
|
|
That's a bit odd. But I assume that it is related to the profile handling, because
Until then: I'd be curious if it prints any warnings when it is started with at the console. |
|
No warning was displayed on the console. |
|
Thanks for testing this! To be sure: In the case where it does not work (Intel Graphics + JOGL), the only problem is that it disappears when "Fit camera" was clicked, right? (I can only guess why this happens. My first guess would be that a 16 bit Z-buffer is used in this configuration, whereas in the other setups, the Z-Buffer has 24 or 32 bits - but this is a wild guess, only based on the symptoms. I'll have to investigate this further) |
Yes! I do not know if it will serve as a clue for the solution, but I thought it would be nice if JglTF had the ability to display the following information.
|
|
I'm not sure - some thoughts
However, I'll add more logging for debugging, always hoping that this will contain relevant information that helps to solve difficult issues like this. (It's always difficult when the error cannot be reproduced...) |
|
I agree. Debug log may be more effective. By the way, I tried it because there is also an old ThinkPad at hand. PC3 : ThinkPad X201 + Intel(R) HD Graphics Unfortunately the environment was old or not working. |
|
EDIT: Something was wrong here. I'll review all this in more detail, and comment later. |
|
I checked version of OpenGL with the following tools. Certainly ThinkPad X201 does not seem to correspond to GL3. PC1 : ThinkPad X260 + (Intel(R) HD Graphics 520 PC2 : Desktop PC + NVIDIA GeForce GTX 660 PC3 : ThinkPad X201 + Intel(R) HD Graphics |
|
Thanks for your support here! Originally, this was my first guess: The core of the message is Not a GL3 implementation which led me to the conclusion that the device simply does not support OpenGL 3.x. (and I thought that a driver update might help, although one cannot be sure). But then, I deleted this comment, because I noticed that the message was printed from a class called Regardless of that, the message "Not a GL3 implementation" was justified. I started adding some options for configuring the logging, and for printing debug information. This relies on the debugging strings from JOGL. For example, when no GL3 instance can be obtained, then it will print something like which isn't entirely trivial to analyze, but at least should contain the most important hints. |
|
ThinkPad X201 is a PC released 6 to 7 years ago. However, I think that it is better to write OpenGL 4.0 or higher as a system requirement of JglTF. |
|
By the way, although it is a simple question, the latest version of LWJGL is 3, but JglTF uses 2. Is there any reason? |
|
The actual requirement should be OpenGL 3.x. There is no need for a higher version - maybe also because I'm not very familiar with GL4, and don't know (yet) where GL4 functionality could be advantageous. (In fact, since glTF itself is targetet at WebGL 1, the functionality of GL3 should be sufficient in any case) The reason of why I'm using LWJGL 2 is simple: The component that is used for rendering is an (This makes LWJGL 3 useless for many applications, and this is a pity. There are some ongoing discussions, e.g. http://forum.lwjgl.org/index.php?PHPSESSID=cndssun5cgfde5gpmrnrsc0jt3&topic=5975.msg32034#msg32034 - but admittedly, I did not yet fully understand what the problem is: In LWJGL 2, it just worked, out of the box - and now it should be completely impossible, even as a separate library? This simply cannot be true. I still hope that they will re-introduce this canvas class in LWJGL 3...) |
Below are some materials that @emadurandal created for WebGL beginners.
If WebGL 1 is the target, it feels good even for GL2. However, I do not understand so much, so it may be that there is a reason for not doing so.
I understood that LWJGL 3 does not support AWTGLCanvas. I found the following library. Maybe this could be used? |
|
Regarding the I have to admit that I don't have an overview over the different GL versions. I learned OpenGL 1.1 with the redbook ~20 years ago, had a long break in the meantime, and only started actively using it again when OpenGL 3.3 came out and the fixed function pipeline was deprecated. But from what I see, the diagram basically conveys the relevant point here: The functionality of WebGL 1.0 is roughly the same as for GLES 2.0 and GL2.0. I could probably retrofit the implementations, so that they also work with GL2.0. In fact, I just had a look: These are the only GL3.0 functions that are used in the viewer implementation right now. So there are two opposite demands: Using a newer LWJGL version, and an older GL version ;-) Of course, both points are valid and reasonable, and could broaden the supported platforms. But I have to admit that they do not have the highest priority right now. Nevertheless, I have summarized them in #13 , to prevent them from being lost. |
|
Thank you for considering the new LWJGL and the old GL version. I also became interested in Java graphics, so I would like to study a bit. |
|
There are not so many applications or users for GL in Java, although there are gaming libraries like http://jmonkeyengine.org/ or https://libgdx.badlogicgames.com/ that offer some really interesting options for cross-platform development. When not using a game engine or library, there is the "big" question: JOGL or LWJGL? Both are very thin layers around OpenGL. This has the advantage that you can translate C++ OpenGL code to Java with minimal modifications. (At least, after you have set up a few lines of boilerplate code, and eventually have the The "disadvantage" is that you have to decide whether you use LWJGL or JOGL, and it may be a bit tedious to switch between both. For JglTF, I created the GlContext class as another (thin) abstraction layer, but this may not be applicable for other application cases. One general issue when using Java+OpenGL (or Java and native APIs in general) is: The native library handling is difficult. (Just do a websearch for BTW, as mentioned in #13 (comment) : I tried LWJGL3, and it works with very few changes compared to LWJGL2. I'll add this as another viewer implementation soon. |
|
Although the game engine is interesting, I feel that footprint is big for glTF viewer.
If switching is troublesome, how about creating two versions of jar instead of all in one? |
|
Maybe there was a misunderstanding: With "switching" I did not mean switching between both renderers at runtime (as it is possible in the With "switching", I here referred to the code chages that may be necessary, when you use LWJGL and later (for whatever reason) decide to use JOGL. Most of these code changes can be done "mechanically", because they mainly (!) consist of renaming the If you want the option to
then things become a bit more complicated. The most straightforward approach here is to define an additional abstraction layer. And this is basically what I did with in JglTF: I defined the interface (aka "abstract class" or "virtual class") called This is solution seemed like an acceptable trade-off for me. However, this interface So to summarize:
I could, of course, create two different "releases" of the
Right now, the releases contain all libraries. I wanted to have a single JAR that can be started with a double-click, and which should work for as many people as possible. That's also a reason of why I wanted to support JOGL and LWJGL: When one of them does not work, the user can still switch to the other one (even though in the best case, this should not be necessary: Both of them should work equally well). But one of the goals was also to offer the option to just use one of the implementations. For example, if someone has an application that already uses LWJGL, then he can pick the main JglTF libraries and the Of course, I could make my life simpler. I could just pick LWJGL to implement the glTF viewer, and if someone uses JOGL, then that's not my problem ;-) But I wanted to support both, and that's what I came up with. Suggestions for improvements are always welcome. Some suggestions are "obvious": I would really like to offer a glTF viewer for Android. That's what #4 aimed at. In the best case, this would "only" mean another implementation of the |
The following model could not be displayed with JglTF.
https://github.com/mrdoob/three.js/tree/dev/examples/models/gltf/snowflake
https://github.com/mrdoob/three.js/tree/dev/examples/models/gltf/snowflakes
Below is an example display of Three.js r84dev + glTF Loader.
http://jsdo.it/cx20/EOVG
I think that JglTF is not display with those with primitive type LINES.
The text was updated successfully, but these errors were encountered: