BUGS 3.33 KB
Newer Older
Jonathan Carter's avatar
Jonathan Carter committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
- Display list mode doesn't render sea on Lenovo S10e with Debian/Lenny.
  Also Ubuntu VMs.
  Hmmm works fine on 64bit Debian/Lenny with Nvidia OpenGL.
  Seems to be mesa-only problem.
  Seems to be a GL error in display list.

- GL area dies on Ubuntu in virtualbox when widget is minimised then restored.
  (Partial fix in code is to recreate GL area when terrain regenerated)

- Sparc etch build doesn't display on Nvidia i386 machine.
  However, nvidia OpenGL i386 build does display on the sparc.

- The Ubuntu dapper built packages seem to have some problems
  when meshes are drawn with glDraw[Range]Elements
  (NB the problem seems to be in the built app, NOT the xserver).
  The confusion seems to occur above the 1k primitives mark.
  Reducing the number of primitives per glDrawRangeElements
  seems to help although some xservers seem to spew
    X Error: GLXBadLargeRequest.
  and give a blank view.  If this happens, increase the
  spinbox from zero; this uses a different render path.
  [I did wonder if this was something to do with Ubuntu using
  the mesa GL libraries and Debian using the XFree86 versions:
    dpkg-query -S /usr/include/GL/gl.h
      Sarge:  xlibmesa-gl-dev: /usr/include/GL/gl.h
      Dapper: mesa-common-dev: /usr/include/GL/gl.h 
  But building the package on Debian Etch against
  (add them into the yadda build dependencies in the mkdeb script)
  doesn't reproduce the problem there.
  Both platforms are gcc 4.0.3.
  It's a mystery!  Any help gratefully received.]
  Haven't tried edgy yet.

- fracplanet running on 64 bit lenny shows missing polys
  (all sea?) when viewed by display list from 32bit lenny mesa

- Bear in mind that selecting display list rendering means a copy
  the GL system takes a copy of the triangle mesh.  This needs memory;
  if there isn't enough the application may crash (some drivers
  may crash if the display list doesn't fit on the graphics card). 

- Base land height doesn't affect noise-only terrain 
  (when vertical perturbation is reduced to zero; probably because
  it's expressed as a proportion of vertical perturbation - should
  just be absolute).

- Blender seems to ignore alpha in the cloud layer, and renders
  it as solid.  It doesn't pass per-vertex alphas out to yafray either.
  This may just be some material flag which needs setting, but haven't
  been able to discover a solution.  Any help appreciated.
  The workround is to emit an opaque pre-blended cloud layer.

- River generation can be VERY slow (especially at high levels of subdivision)
  due to the time taken to fill up large lakes (just like in the real world,
  strangely enough :^): raising the water level slightly to the level of a
  potential outflow currently necessitates adjusting the height of all the
  points in the lake, which takes a long time with big lakes.  The progress
  dialog gives a bit more feedback about this now.  It WILL complete;
  just give it time.

- Flat (non-planet) terrain mostly disappears when viewed from beneath due
  to back-face culling.

- Export to Blender doesn't support emissive terrain.

- Doing the clouds as a mesh might seem pointless but there
  are plans to perturb the mesh to produce weather systems.
  Maybe add some height too.