castle-engine / demo-models

Demo 3D models (mostly in X3D and VRML formats) of view3dscene and Castle Game Engine
https://castle-engine.io/demo_models.php
17 stars 12 forks source link

incomplete rendered texture #3

Closed andreasplesch closed 6 years ago

andreasplesch commented 6 years ago

in https://github.com/castle-engine/demo-models/blob/master/rendered_texture/rendered_texture_with_background.x3dv

image

However, if size is reduced to 512 the texture is complete.

michaliskambi commented 6 years ago

Looks like the possible texture size (or cubemap face size?) of your GPU / OpenGL is smaller than requested in the file (1024). View3dscene (actually, Castle Game Engine) then automatically uses a smaller size (512). But it seems that something is wrong, and it still tries to use a larger size (1024) elsewhere.

I cannot reproduce it here, for me even GeneratedCubeMapTexture { update "ALWAYS" size 4096 } works (although updating it every frame is slow). The size 8192 does not work OK for me, but there's a fair warning "Unsupported framebuffer configuration, will fallback to glCopyTexSubImage2D approach", so I'm not sure is this the same problem as you have.

  1. Does view3dcene show any warnings for you? (File -> View Warnings)

  2. Can you generate the debug log (it contains various information about your GPU) by running on the command-line view3dscene --debug-log -> log.txt, and attach log.txt here?

  3. The rendered_texture_with_background.x3dv also has a Box on the right with RenderedTexture, but you commented that out, right? You're testing only with Teapot covered by GeneratedCubeMapTexture?

Thanks!

Here's how the complete rendered_texture_with_background.x3dv should look like, for reference:

rendered_texture_with_background_0

andreasplesch commented 6 years ago

On Sat, Jan 20, 2018 at 7:56 PM, Michalis Kamburelis < notifications@github.com> wrote:

Looks like the possible texture size (or cubemap face size?) of your GPU / OpenGL is smaller than requested in the file (1024). View3dscene (actually, Castle Game Engine) then automatically uses a smaller size (512). But it seems that something is wrong, and it still tries to use a larger size (1024) elsewhere.

The GPU is Intel HD Graphics 3000/4000.

I cannot reproduce it here, for me even GeneratedCubeMapTexture { update "ALWAYS" size 4096 } works (although updating it every frame is slow). The size 8192 does not work OK for me, but there's a fair warning "Unsupported framebuffer configuration, will fallback to glCopyTexSubImage2D approach", so I'm not sure is this the same problem as you have.

1.

Does view3dcene show any warnings for you? (File -> View Warnings)

Yes: VRML/X3D warning: OpenGL implementation doesn't allow any glGenerateMipmap* version, so you cannot use mipmaps for GeneratedCubeMapTexture

1.

Can you generate the debug log (it contains various information about your GPU) by running on the command-line view3dscene --debug-log -> log.txt, and attach log.txt here?

see below and attached from --debug-log-shaders

1.

The rendered_texture_with_background.x3dv also has a Box on the right with RenderedTexture, but you commented that out, right? You're testing only with Teapot covered by GeneratedCubeMapTexture?

Yes, the Box is commented out.

1.

Thanks!

Log for "view3dscene". Version: 3.17.0. Started on 2018-01-21 at 7:07:55.
Castle Game Engine version: 6.3 (unstable).
Compiled with: FPC 3.0.4 (Win32 / i386).
-------------------- OpenGL context initialization begin
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-specific 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): 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

------------------------
Real versions available:
(checks both version string and actual functions availability in GL
library, to secure from buggy OpenGL implementations)

  1.2: True
  1.3: True
  1.4: True
  1.5: True
  2.0: True
  2.1: True
  3.0: True
  3.1: True
  3.2: False
  3.3: False
  4.0: False

---------
Features:
  Shaders (GLSL) support: Standard
  => Enable deprecated (fixed-function) support: False
  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

  All extensions: GL_EXT_blend_minmax GL_EXT_blend_subtract
GL_EXT_blend_color GL_EXT_abgr GL_EXT_texture3D GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array GL_SGIS_texture_edge_clamp
GL_SGIS_generate_mipmap GL_EXT_draw_range_elements GL_SGIS_texture_lod
GL_EXT_rescale_normal GL_EXT_packed_pixels GL_EXT_texture_edge_clamp
GL_EXT_separate_specular_color GL_ARB_multitexture
GL_EXT_texture_env_combine GL_EXT_bgra GL_EXT_blend_func_separate
GL_EXT_secondary_color GL_EXT_fog_coord GL_EXT_texture_env_add
GL_ARB_texture_cube_map GL_ARB_transpose_matrix GL_ARB_texture_env_add
GL_IBM_texture_mirrored_repeat GL_EXT_multi_draw_arrays GL_NV_blend_square
GL_ARB_texture_compression GL_3DFX_texture_compression_FXT1
GL_EXT_texture_filter_anisotropic GL_ARB_texture_border_clamp
GL_ARB_point_parameters GL_ARB_texture_env_combine GL_ARB_texture_env_dot3
GL_ARB_texture_env_crossbar GL_EXT_texture_compression_s3tc GL_ARB_shadow
GL_ARB_window_pos GL_EXT_shadow_funcs GL_EXT_stencil_wrap
GL_ARB_vertex_program GL_EXT_texture_rectangle GL_ARB_fragment_program
GL_EXT_stencil_two_side GL_ATI_separate_stencil GL_ARB_vertex_buffer_object
GL_EXT_texture_lod_bias GL_ARB_occlusion_query GL_ARB_fragment_shader
GL_ARB_shader_objects GL_ARB_shading_language_100
GL_ARB_texture_non_power_of_two GL_ARB_vertex_shader
GL_NV_texgen_reflection GL_ARB_point_sprite GL_ARB_fragment_program_shadow
GL_EXT_blend_equation_separate GL_ARB_depth_texture
GL_ARB_texture_rectangle GL_ARB_draw_buffers GL_ARB_color_buffer_float
GL_ARB_half_float_pixel GL_ARB_texture_float GL_ARB_pixel_buffer_object
GL_EXT_framebuffer_object GL_ARB_draw_instanced GL_ARB_half_float_vertex
GL_ARB_occlusion_query2 GL_EXT_draw_buffers2 GL_WIN_swap_hint
GL_EXT_texture_sRGB GL_ARB_multisample GL_EXT_packed_float
GL_EXT_texture_shared_exponent GL_ARB_texture_rg
GL_ARB_texture_compression_rgtc GL_NV_conditional_render
GL_EXT_texture_swizzle GL_ARB_sync GL_ARB_framebuffer_sRGB
GL_EXT_packed_depth_stencil GL_ARB_depth_buffer_float
GL_EXT_transform_feedback GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample GL_ARB_framebuffer_object
GL_EXT_texture_array GL_EXT_texture_integer GL_ARB_map_buffer_range
GL_EXT_texture_snorm GL_INTEL_performance_queries GL_ARB_copy_buffer
GL_ARB_sampler_objects GL_NV_primitive_restart GL_ARB_seamless_cube_map
GL_ARB_uniform_buffer_object GL_ARB_depth_clamp GL_ARB_vertex_array_bgra
GL_ARB_shader_bit_encoding GL_ARB_draw_buffers_blend
GL_ARB_texture_query_lod GL_ARB_explicit_attrib_location
GL_ARB_draw_elements_base_vertex GL_ARB_instanced_arrays
GL_ARB_fragment_coord_conventions GL_EXT_gpu_program_parameters
GL_ARB_texture_buffer_object_rgb32 GL_ARB_compatibility
GL_ARB_texture_rgb10_a2ui GL_ARB_vertex_type_2_10_10_10_rev
GL_ARB_timer_query GL_INTEL_map_texture GL_ARB_vertex_array_object
GL_ARB_provoking_vertex

-----------------------------
OpenGL utility (GLU) version:
  Version string: 1.2.2.0 Microsoft Corporation
  Version parsed: major: 1, minor: 2, release exists: True, release: 2,
vendor-specific information: ".0 Microsoft Corporation"
  Extensions: GL_EXT_bgra

---------------------------
Current buffers bit depths:
  Color (red / green / blue / alpha): 8 / 8 / 8 / 8
  Depth: 24
  Index: 32
  Stencil: 8
  Accumulation (red / green / blue / alpha): 16 / 16 / 16 / 16
  Double buffer: True
  Multisampling (full-screen antialiasing): True
    Current: 1 samples per pixel

-------------
Stack depths:
  Attributes: 16
  Client attributes: 16
  Modelview: 32
  Projection: 4
  Texture: 10
  Name: 128

-------
Limits:
  Max clip planes: 6
  Max lights: 8
  Max eval order: 32
  Max list nesting: 64
  Max pixel map table: 65536
  Max texture size: 8192
  Max viewport dims: width 8192 / height 8192
  Max texture units: 8
  Max cube map texture size: 8192
  Max 3d texture size: 2048
  Max texture max anisotropy: 16
  Query counter bits (for occlusion query): 64
  Max renderbuffer size: 4096

-------
Memory (in Kb):
  Total: 0 (unknown)
  Current: 0 (unknown)
  Current for VBO: 0 (unknown)
  Current for Textures: 0 (unknown)
  Current for Renderbuffers: 0 (unknown)
-------------------- OpenGL context initialization end

Here's how the complete rendered_texture_with_background.x3dv should look like, for reference:

snip

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/castle-engine/demo-models/issues/3#issuecomment-359214623, or mute the thread https://github.com/notifications/unsubscribe-auth/AF4p66C1PmtemnmmEnVuvNoUrtcSYI1hks5tMotBgaJpZM4RlR93 .

-- Andreas Plesch Waltham, MA 02453

michaliskambi commented 6 years ago

I see that the GLVersion.BuggyFBOCubeMap is set in your case. See https://github.com/castle-engine/castle-engine/blob/master/src/base/opengl/castleglversion.pas#L132 . In this case, we fallback to rendering without FBO. We render to the regular back buffer of your window, and then use glCopyTexSubImage2D to copy the buffer contents to your texture.

One of the drawbacks of this approach (besides the fact that it's slower) is that the size is limited by your current window size (which in turn is limited by Windows to your desktop size).

It would be simplest to make BuggyFBOCubeMap = false in your case. I tried it now, and the new view3dscene should be built on http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ . Can you download it, and

  1. check that now "Buggy FBO rendering to cube map texture" is False (besides being visible in --debug-log, this report is also visible if you enter menu item Help -> OpenGL Information).

  2. and then check how does the cubemap look?

  3. Unrelated to this particular issue, if we manage to solve this like this, I may ask you for some additional tests on your GPU :) We have some more things that are disabled on Intel GPU, and looking at the code I think they may be "disabled too widely". They can possibly be enabled on newer driver versions.

michaliskambi commented 6 years ago

The new view3dscene should be built on http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ now:)

andreasplesch commented 6 years ago

ok, looks good with the snapshot.

image image

Intel HD4400 on win10pro (Dell Latitude 7240)

michaliskambi commented 6 years ago

OK, good that it works. Thanks for testing!

  1. Can you also test on your older Intel GPU? The GPU from your previous comment was older, as far as OpenGL is concerned:
Version string: 3.1.0 - Build 9.17.10.3040 
Renderer: Intel(R) HD Graphics 3000

The new one has:

Version string: 4.3.0 - Build 20...
Renderer: Intel(R) HD Graphics 4400

So that was an older graphic card model (3000 vs 4400), with an older driver (Build 9 vs Build 20) exposing an older OpenGL API (3.1 vs 4.3). In particular, the difference in driver version (Build 9 vs Build 20) can be significant in my experience, new version may be more stable.

So, if you have access to it, please also test on that older GPU. My "fix" keeps BuggyFBOCubeMap as "true" for Build versions <= 8, and "false" for Build versions >= 9.

  1. Unrelated to this issue, if I can, I would like to use your access to Intel GPUs on Windows to test additional fix :) I just committed additional change to CGE, that makes "glGenerateMipmap" no longer considered "buggy".

In effect, the warning "OpenGL implementation doesn't allow any glGenerateMipmap* version..." should disappear, and in Help -> OpenGL Information you should see GenerateMipmap available (and reliable): True, and in general this GPU will be treated like a normal non-buggy modern GPU.

I would very much appreciate if you would test the newest version of view3dscene on both your Intel GPUs (4400 and 3000). Simply open rendered_texture_with_background.x3dv and check is it fine. (You can also check other things in https://github.com/castle-engine/demo-models/tree/master/rendered_texture and https://github.com/castle-engine/demo-models/tree/master/cube_environment_mapping . But the rendered_texture_with_background.x3dv is probably the most important one, it's trivial and it exercises both cubemaps and regular 2D texture.)

http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ already contains the updated view3dscene version. Thank you!

andreasplesch commented 6 years ago

Yes, here is the older HD3000 test with the latest snapshot: image image The mipmap warning disappeared as well.

michaliskambi commented 6 years ago

Great! Thank you for testing -- so I'm closing this issue, as everything seems fixed:)

andreasplesch commented 6 years ago

Just for future reference on HD3000, win7:

render_texture_tweak_size: after pressing s four times:

view3dscene: VRML/X3D warning: Framebuffer error, generated texture not possible : Maximum renderbuffer (within framebuffer) size is 4096 x 4096 in your OpenGL i mplementation, while we require 8192 x 8192

This seems ok, 4k textures.

shaders:

view3dscene: VRML/X3D warning: Cannot use GLSL shader for shape "Sphere": Geomet ry shaders not supported by your OpenGL version

two_textures.x3dv view3dscene: VRML/X3D warning: Cannot use GLSL shader for shape "IndexedFaceSet" : Fragment shader not compiled: WARNING: 0:12: 'texture2D' : implicit conversion is allowed from GLSL 1.20 ERROR: 0:12: 'texture2D' : no matching overloaded function found (using implicit conversion) WARNING: 0:13: 'texture2D' : implicit conversion is allowed from GLSL 1.20 ERROR: 0:13: 'texture2D' : no matching overloaded function found (using implicit conversion) ERROR: 0:11: 'assign' : cannot convert from 'const float' to 'FragColor 4-compo nent vector of float'

cellular_texturing.x3dv: slow 10fps cellular_texturing_mirror_fun.x3d: 1fps

michaliskambi commented 6 years ago

We only support geometry shaders since OpenGL 3.2 (see https://castle-engine.sourceforge.io/x3d_implementation_shaders.php#section_geometry_old ). So this is OK too, if you test on older GPU (your "Intel(R) HD Graphics 3000" has OpenGL 3.1).

two_textures.x3dv warnings: should be fixed, but please test (I could not reproduce them, I sit on NVidia GPU now and it's less strict about some GLSL constructs).

cellular_texturing slowness: that's also OK, I'm afraid, these demos do something really heavy in the shader :)

andreasplesch commented 6 years ago

Just a few observations on the HD4400 cellular_texturing.x3dv : >60fps (!) cellular_texturing_mirror_fun.x3d: >60 fps(!) but looks a little strange (very red)

render_texture_tweak_size: after pressing s five times: 8k tex still ok.

Logger "L": received field "set_dimensions" (MFInt32). Time: 13.81. Sending node: "MyScript" (Script). Value: set_dimensions [ 16384, 16384, ] view3dscene: OpenGL warning: Check errors before checking FBO status OpenGL error (1285): There is not enough memory left to execute the command. view3dscene: VRML/X3D warning: Framebuffer error, generated texture not possible: Framebuffer check failed: INCOMPLETE_ATTACHMENT: Not all framebuffer attachment points are "framebuffer attachment complete" (FBO error number 36054)

geometry_shader.x3dv (with OpenGL 4.3)

view3dscene: VRML/X3D warning: Cannot use GLSL shader for shape "Sphere": Geometry shader not compiled: ERROR: 0:30: '[' : layout must be declared before indexing unsized varying input array with a variable ERROR: 0:31: '[' : layout must be declared before indexing unsized varying input array with a variable ERROR: 0:33: '[' : layout must be declared before indexing unsized varying input array with a variable ERROR: 0:52: '[' : layout must be declared before indexing unsized varying input array with a variable ERROR: 0:53: '[' : layout must be declared before indexing unsized varying input array with a variable ERROR: 0:55: '[' : layout must be declared before indexing unsized varying input array with a variable

two_textures.x3dv: view3dscene: VRML/X3D warning: Cannot use GLSL shader for shape "IndexedFaceSet": Fragment shader not compiled: WARNING: 0:4: '' : #version directive missing ERROR: 0:12: 'texture2D' : no matching overloaded function found (using implicit conversion) ERROR: 0:14: 'texture2D' : no matching overloaded function found (using implicit conversion) ERROR: 0:12: 'assign' : cannot convert from 'const mediump float' to 'FragColor 4-component vector of mediump float'

michaliskambi commented 6 years ago

cellular_texturing_mirror_fun.x3d: >60 fps(!) but looks a little strange (very red)

The red is correct -- it has a red background, and everything is a mirror, so everything gets red-tainted.

render_texture_tweak_size with 16384

At some point, the error "There is not enough memory left to execute the command" is unavoidable, I'm afraid. It's the one OpenGL error that can in theory occur always, and is beyond the control of the application. We check things like Width > GLFeatures.MaxRenderbufferSize earlier (where MaxRenderbufferSize = glGetInteger(GL_MAX_RENDERBUFFER_SIZE)), but it does not guarantee that we will avoid "out of memory" error.

geometry_shader.x3dv two_textures.x3dv

Hm, I would have to experiment a bit to understand what is the problem with GLSL code there. It works on my current GPU (NVidia on Linux). I'll keep on eye on them. I'll also separate these to a separate bugreport, to not forget it.

andreasplesch commented 6 years ago

Ok.