some collada files not rendered about view3dscene HOT 16 CLOSED

The https://raw.githubusercontent.com/andreasplesch/glTF-Sample-Models/master/sourceModels/2CylinderEngine/2CylinderEngine.dae has transparency = 1.0:

<transparency>
  <float>1.000000</float>
</transparency>

It results in transparency = 1.0 in X3D material, when view3dscene/Castle Game Engine reads this.

Besides investigating the DAE, you can also see this:

• Selecting the shape triangle with Ctrl + right click in view3dscene, and then use "Help -> Selected Object Information". It shows the information about material.

• You can also save it from view3dscene back to X3D ("File -> Save As ...") and look at resulting Material nodes. This also offers a simple way to fix this model: just search/replace in classic X3D "transparency 1" with "# transparency 1" and the model is OK.

• You can also use "View -> Fill Mode -> Solid Wireframe" to confirm that indeed the material is wrong, but geometry is OK :)

Buggy, GearboxAssy: The same answer.

So, the question is: is this a bug of view3dscene / Castle Game Engine, or these models?

They definitely have:

<transparency>
  <float>1.000000</float>
</transparency>

They also have:

<transparent opaque="A_ONE">
  <color>1.000000 1.000000 1.000000 1</color>
</transparent>

(And my own comments indicate that both these transparency values should be multiplied: https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dloadinternalcollada_effects.inc#L159 ).

So, as far as I can see, the view3dscene / Castle Game Engine is correct: these Collada models have (final) transparency 1.0.

• Can you see what/why generated this transparency 1.0?
• Is there some other Collada viewer that shows them opaque (and honors material transparency otherwise)?
• Does the Collada specification says something different than we do?
• Maybe the opaque="A_ONE" be interpreted to mean that it's always opaque (effectively making the values of and ignored? We ignore this attribute now, as far as I see.

from view3dscene.

Rereading Collada specification, it seems that opaque="A_ONE" basically means to use 1 - transparency (it would be more accurately called "opacity"). The full issue is a bit more complicated ( https://www.khronos.org/files/collada_spec_1_4.pdf ), but that's the main point :)

I fixed it in the Castle Game Engine. New view3dscene from http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ should be OK :)

Sorry for such long answer above:) Everything should work now.

from view3dscene.

Hm, I am having trouble with the latest snapshot. Opening a local copy of 2CylinderEngine.dae now crashes view3dscene with

and Duck.dae is now black but with the correct the mesh.

from view3dscene.

Hm, that's very weird. I cannot reproduce it -- testing on Linux, testing on Windows, even testing just the view3dscene downloaded from http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ for both 32-bit Windows and 64-bit Windows. Both Duck and 2CylinderEngine.dae work OK for me -- no crashes, and correct colors.

The error message you show (assertion failure with wgfIfMergeOpt.cpp) does not seem to come from view3dscene or any library we use. Googling, nothing conclusive. Are you sure you're using view3dscene, the original unmodified view3dscene binary from http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ ?

from view3dscene.

from view3dscene.

My testing earlier today was on Windows 7 64-bit too. (Although in a virtual machine, but that shouldn't matter.)

from view3dscene.

I tested the 32bit version on 64bit Windows 10 and it worked fine.

from view3dscene.

Thanks for testing. I was also testing 2CylinderEngine.dae and Duck.dae on another Windows (8.1 64-bit, with 64-bit view3dscene binary), and they work fine.

Can you still reproduce the problems on your Windows 7 (assertion failure with wgfIfMergeOpt.cpp, and black duck)? It seems like a very serious bug, so I would very much want to fix it... except I can't seem to reproduce it, and both problems are rather mysterious. If you can still reproduce it, I would ask you for some additional tests. First of all, to test that older view3dscene (you can just take one from https://castle-engine.sourceforge.io/view3dscene.php ) definitely did not crash, to eliminate the fact that something in your environment changed.

from view3dscene.

I still get the same error on 64bit Windows 7 SP1, 3GB RAM with the 32bit and 64bit v3d snapshots. Significantly, I find that many other scenes trigger this. The simplest one sofar is:

http://www.web3d.org/x3d/content/examples/ConformanceNist/Appearance/Appearance/material.x3d

I had a 3.15.0 version still installed which still works fine.
3.17.0 (https://sourceforge.net/projects/castle-engine/files/view3dscene/old_versions/view3dscene-3.17.0-win-i386.zip/download) works fine.
I downloaded the current release 3.18.0 version from 1/21 now and it already had the same error.

After I click Retry I get this Exception:

ok then shows:

from view3dscene.

Probably related are strange artefacts in scenes that do not crash.

http://www.web3d.org/x3d/content/examples/ConformanceNist/Geometry/Box/default_box.x3d

with solid wireframe looks like this:

from view3dscene.

"External exception" indicates that something fails in a dll we use. The weirdness of other symptoms, and the Access Violation (it's a segfault, that may also come from external library) suggests that the OpenGL has serious bugs. Which unfortunately can happen on Intel GPUs, but our other results were so promising...

Things that would be useful to check:

• run view3dscene 3.18.0 with and without command-line option --debug-enable-fixed-function. Does it help? That's a major change in view3dscene 3.18.0. If this is the culprit, we should blacklist this GPU as having unreliable shaders.

• if you can find some GPU driver updates and try installing them, that would be helpful too. Intel has updates to Windows drivers on https://downloadcenter.intel.com/ , although your laptop manufacturer may have most suitable ones.

from view3dscene.

Ok. I will try --debug-enable-fixed-function on the 64bit Windows7SP1 laptop.

On my 32bit Windows7SP1, 4GB RAM, Intel HD3000 laptop there are no issues. Here is its OpenGL information:

OpenGL information (detected by view3dscene):

--------
Version:
  Version string: 3.1.0 - Build 9.17.10.3040
  Version parsed: major: 3, minor: 1, release exists: True, release: 0, vendor-s
pecific information: "- Build 9.17.10.3040"
  Vendor-specific version parsed: major: 9, minor: 17, release: 10
  Vendor: Intel
  Vendor type: Intel

  Renderer: Intel(R) HD Graphics 3000
  Fglrx (ATI on Linux): False
  Mesa: False

  Buggy glGenerateMipmap(EXT): False
  Buggy GL_LIGHT_MODEL_TWO_SIDE: False
  Buggy VBO: False
  Buggy shader shadow map: False
  Buggy FBO rendering to multi-sampling texture: True
  Buggy FBO rendering to cube map texture: False
  Buggy swap buffers with non-standard glViewport: False
  Buggy 32-bit depth buffer: False
  Buggy GLSL gl_FrontFacing: False
  Buggy GLSL read varying: False

------------------------

from view3dscene.

The switch --debug-enable-fixed-function did help with 3.18.0 release on my 64bit Windows7SP1 Dell Inspiron 15 N5040 HD Graphics. Dell does not have updated Intel Graphics drivers.

Here the OpenGL info:

OpenGL information (detected by view3dscene):

--------
Version:
  Version string: 2.1.0 - Build 8.15.10.2342
  Version parsed: major: 2, minor: 1, release exists: True, release: 0, vendor-s
pecific information: "- Build 8.15.10.2342"
  Vendor-specific version parsed: major: 8, minor: 15, release: 10
  Vendor: Intel
  Vendor type: Intel

  Renderer: Intel(R) HD Graphics
  Fglrx (ATI on Linux): False
  Mesa: False

  Buggy glGenerateMipmap(EXT): True
  Buggy GL_LIGHT_MODEL_TWO_SIDE: False
  Buggy VBO: False
  Buggy shader shadow map: False
  Buggy FBO rendering to multi-sampling texture: True
  Buggy FBO rendering to cube map texture: True
  Buggy swap buffers with non-standard glViewport: False
  Buggy 32-bit depth buffer: False
  Buggy GLSL gl_FrontFacing: False
  Buggy GLSL read varying: False

------------------------

from view3dscene.

Thanks! So I "blacklisted" Intel GPUs on Windows with driver version <= 8, to not do "pure shader pipeline" on them (effectively, behaving like --debug-enable-fixed-function by default).

As usual, http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ will soon have the latest version and I would appreciate testing. You should see that (on Windows Intel GPU with driver version <= 8) the OpenGL information contains

• Buggy Pure Shader Pipeline: True and
• Enable deprecated (fixed-function) support: True.

from view3dscene.

I tested both the latest 32bit and 64bits snapshots and both now work correctly.

--------
Version:
  Version string: 2.1.0 - Build 8.15.10.2342
  Version parsed: major: 2, minor: 1, release exists: True, release: 0, vendor-s
pecific information: "- Build 8.15.10.2342"
  Vendor-specific version parsed: major: 8, minor: 15, release: 10
  Vendor: Intel
  Vendor type: Intel

  Renderer: Intel(R) HD Graphics
  Fglrx (ATI on Linux): False
  Mesa: False

  Buggy glGenerateMipmap(EXT): True
  Buggy GL_LIGHT_MODEL_TWO_SIDE: False
  Buggy VBO: False
  Buggy shader shadow map: False
  Buggy FBO rendering to multi-sampling texture: True
  Buggy FBO rendering to cube map texture: True
  Buggy swap buffers with non-standard glViewport: False
  Buggy 32-bit depth buffer: False
  Buggy GLSL gl_FrontFacing: False
  Buggy GLSL read varying: False
  Buggy Pure Shader Pipeline: True
...
---------
Features:
  Shaders (GLSL) support: Standard
  => Enable deprecated (fixed-function) support: True
  Multi-texturing: True
  Framebuffer Object: Standard (or ARB "core extension")
  Multi-sampling for FBO buffers and textures: False
  Vertex Buffer Object: True
  GenerateMipmap available (and reliable): False
  Cube map textures: Standard
  Compressed textures supported: [DXT1_RGB, DXT1_RGBA, DXT3, DXT5]
  3D textures: Standard
  Textures non-power-of-2: True
  Blend constant parameter: True
  Float textures: True
  Depth textures: True
  Packed depth + stencil: True

from view3dscene.

Great! Thank you!

from view3dscene.