ceedee

Members
  • Content count

    18
  • Joined

  • Last visited

  1. debugLayer - Uncaught TypeError

    Hi Chromium "61.0.3163.100 (Official version) Built on Ubuntu , running on Ubuntu 17.04 (64-bit)" but this happens on Firefox as well, only message is a little bit different ( version 56.0 64-bit, Ubuntu as well, Xubuntu 17.04 exactly ) Frefox message: TypeError: i is null[Więcej informacji] babylon.inspector.bundle.js:408:5002 INSPECTOR</t.prototype.openPopup http://webgl.local:3000/js/babylon.inspector.bundle.js:408:5002 t http://webgl.local:3000/js/babylon.inspector.bundle.js:408:464 t.prototype._createInspector http://webgl.local:3000/js/babylon3.0.custom.js:37:5625 t.prototype.show On Chromium Windows 7 it is similar, BUT browser shows there information about blocked popup. So I added my website to exception list in popup blocking options, after that it started to work, and no errors in console. It was a bit confusing, because popup worked fine when it was creaded by user click, so blocking is only about automated popup show. So looks like console error is only because code assumes popup was always created correctly and not blocked.
  2. debugLayer - Uncaught TypeError

    Hi I am trying to enable debugLayer in babylon.3.0.7 It only happens when i set popup property. scene.debugLayer.show({ popup:true, initialTab : 2 }); and I get this error in console: Uncaught TypeError: Cannot read property 'document' of null at t.openPopup (babylon.inspector.bundle.js:408) at new t (babylon.inspector.bundle.js:408) at t._createInspector (babylon3.0.custom.js:37) at t.show (babylon3.0.custom.js:37)
  3. Hello Thanks guys for help. I have made some progress. Here is the result: http://www.babylonjs-playground.com/#1OJL6I#68 It is something which we could call a "visibility probe", something like a poor man's occlusion query system but for a bit different purpose. It renders 6 textures of cube around main camera. Then reads textures using modified version of engine.readPixels and analyzes visibility of all meshes. Meshes indexes are color coded into textures. Yo can see visible list of indexes at black bar at the top of the screen. Use mouse and arrow keys to fly between meshes. This way you can do 1 render of texture per frame _at most_. What i need is do arbitrary number of renderings of the same texture, per frame, before render main screen. This is because i need to put on the scene arbitrary number of those visibility probes, but it will be waste of texture memory, because each probe needs 6 textures. So using just one probe used multiple times before main render is preffered. Your method is a bit slow, you use main screen rendering instead of render texture, and recreate texture every time. But it gave me an idea. Instead of using DumpFramebuffer and recreating texture i looked into babylon source and found engine.readPixels, and i made custom version of it which does not allocates new TypedArray every time but uses same one. And used it in after render observable of renderTargetTexture @Deltakosh I will be doing that "visibility probe" again but as a proper class. (what I made in PG is just a messy but working prototype ) Are you interested in putting such component into the library ? One more time thanks for helping.
  4. Fog is closer at center of view

    Whoa. It now looks much better. Does it change performance much? Maybe it makes sense to add this feature as an option in fog settings, for example as scene.fogMode=BABYLON.Scene.FOGMODE_LINEAR_DISTANCE | FOGMODE_EXP_DISTANCE | FOGMODE_EXP2_DISTANCE ?
  5. Thanks Deltakosh for the reply. Your solution works fine in this case. But it takes away from me the control of render which I have in case when i do manually renderTargetTexture.render(). The playground I made is simple with just one render on the texture because this way it was easier to explain the issue, and keep the question as clear as possible. What i really want to achieve is something like that: 1) render scene on the texture, then 2) analyze the texture image ( reading directly rgb values or other method, does not matter yet at this stage of my project) 3) move texture camera a bit, maybe rotate it, change some other settings, etc 4) repeat steps 1-3 few times, actual amount of repetitions may be different every time 5) saving information from analysis (step 2) in an array ( object, cache or whatever ) for later usage 6) render final scene in main render, optionally using information from analysis if it is usable. Is it possible to do it in your way ( scene.customRenderTargets.push(renderTargetTexture); ) ? It seems to be hard as in this case rendering is executed automatically. Or do it with manual executions of renderTargetTexture.render(), but in way which gives proper/expected results ? (As a side question It is interesting why it does not give currently expected results, is it a bug, or maybe I don't understand something.)
  6. Fog is closer at center of view

    Looks like fog depends on Z value of Z-buffer instead of using the calculated distance from camera. I have seen this effect in many games. Probably fog which depends on distance works much slower, but it should be possible to modify shader in that way.
  7. It is not easy to explain things properly, so to make things more clear I prepared some more screenshots. They were made using PG from my first post in this topic ( http://www.babylonjs-playground.com/#1OJL6I#8 ) The behavior described happens in the playground and without playground as well. Without playground instead of moving slider one can resize the browser window to see that. first pair for doNotChangeAspectRatio=true , in both slider positions: Second one for doNotChangeAspectRatio=false
  8. Thanks, but unfortunately this does not help, image on the texture still changes its ratio. Answering your question, i don't use any libs in my tests, only playground, and files saved from playground using "Get .zip" button run locally. I suppose the problem has something to do with this file: https://github.com/BabylonJS/Babylon.js/blob/master/src/Materials/Textures/babylon.renderTargetTexture.ts in line 333 and 344 which both are: if (!this._doNotChangeAspectRatio) { scene.updateTransformMatrix(true); } Why i think that. As far as i know those matrices have encoded both aspect ratio and camera position. So when parameter doNotChangeAspectRatio=true it does not update the matrix so position of camera assigned to texture is completely ignored ( in my PG i linked earlier, there are 2 cameras, one for scene and one for texture) and texture uses same camera position as main screen exactly like on screenshots I posted. I think matrices should be updated in both cases of doNotChangeAspectRatio parameter, but in different way depending on its value ( updating both aspect ratio and camera position or only camera position ) Matrices may have something to with the second issue i described as well, which is strange behavior of specular reflections. Does what I wrote make any sense? Things get even stranger in this PG: http://www.babylonjs-playground.com/#1OJL6I#10 the difference in this PG i that it uses only one camera for both main render and texture render. In this one when doNotChangeAspectRatio=true the image on texture changes it's width like earlier, when using slider. When doNotChangeAspectRatio=false aspect ratio of image rendered on texture does not change BUT main render do not resize anymore and is stretched when using slider. Looks like doNotChangeAspectRatio in some way is "leaking" to main render from RenderTargetTexture constructor. This behavior happens in both playground and locally saved fullscreen version without editor ( you only need to remove #canvasZone div and leave the canvas itself intact to see it properly). I do my testing on chromium 55.0.2883.87
  9. Hi I created the topic first in questions sections, but it seems to look like a bug now. so here is the original topic:
  10. Hi It looks like playground stopped working in newest babylon 2.6. Firefox 51.0.1 x64 Xubuntu 16.04, Nvidia NVS 3100m, proprietary official nvidia driver v340.101 But works fine in chromium 55.0.2883.87 In every scene i opened, even very simple it shows in console something like this: (for example this one: http://playground.babylonjs.com/?2# ) BJS - [08:04:01]: Unable to compile effect: babylon.js:3:21936 BJS - [08:04:01]: Defines: #define SPECULARTERM #define NORMAL #define NUM_BONE_INFLUENCERS 0 #define BonesPerMesh 0 #define LIGHT0 #define HEMILIGHT0 babylon.js:3:21936 BJS - [08:04:01]: Error: 0(4) : error C0203: extension GL_ARB_gpu_shader5 not supported in profile gp4_1vp babylon.js:3:21936 BJS - [08:04:01]: Vertex shader:default babylon.js:3:21936 BJS - [08:04:01]: Fragment shader:default babylon.js:3:21936 BJS - [08:04:01]: Trying next fallback. babylon.js:3:21936 BJS - [08:04:01]: Unable to compile effect: babylon.js:3:21936 BJS - [08:04:01]: Defines: #define NORMAL #define NUM_BONE_INFLUENCERS 0 #define BonesPerMesh 0 #define LIGHT0 #define HEMILIGHT0 babylon.js:3:21936 BJS - [08:04:01]: Error: 0(4) : error C0203: extension GL_ARB_gpu_shader5 not supported in profile gp4_1vp babylon.js:3:21936 BJS - [08:04:01]: Vertex shader:default babylon.js:3:21936 BJS - [08:04:01]: Fragment shader:default babylon.js:3:21936 BJS - [08:04:01]: Unable to compile effect: babylon.js:3:21936 BJS - [08:04:01]: Defines: babylon.js:3:21936 BJS - [08:04:01]: Error: 0(4) : error C0203: extension GL_ARB_gpu_shader5 not supported in profile gp4_1vp babylon.js:3:21936 BJS - [08:04:01]: Vertex shader:color babylon.js:3:21936 BJS - [08:04:01]: Fragment shader:color babylon.js:3:21936
  11. Your reply was confusing, but the edit even more confusing. Could you explain?
  12. Hi I was experimenting with RenderTargetTexture and have some problems. Here is playground http://www.babylonjs-playground.com/#1OJL6I#7 Scene is rendered on texture using camera txcam. And then same objects are rendered on main screen buffer. Here are problems: 1) Aspect ratio and camera for RenderTargetTexture When you drag the splitting line (the one betwean editor and scene) or just disable editor using "-Editor" button, the image on texture changes its aspect ratio, which is not good in my case. So i added false ( true actually does nothing there) for parameter doNotChangeAspectRatio in RenderTargetTexture constructor ( line 38 in playground ) http://www.babylonjs-playground.com/#1OJL6I#8 Now the texture indeed do not changes aspect ratio but texture completely ignores the camera which i chosen for it (txcam) and uses the main camera used in scene. 2) When you look back on first playground ( http://www.babylonjs-playground.com/#1OJL6I#7 ) and you move the camera around with mouse, specular light on rendered texture moves, but should not move at all. That black ball is actually a light source ( it appears in main render as well) , its position is not moving so specular should not too. I will appreciate if someone helps. Maybe those are bugs, or I am do something in wrong way ? regards ceedee
  13. parallax mapping, directional light bug

    Sorry for so late answer, i was too busy in last weeks So i have made another test to be sure. I have taken the playground from paralax tutorial, and changed it a bit, but textures and scene is basicly same. http://playground.babylonjs.com/#10I31V#93 It is one light moving around cube, in the initial camera position you see front side of cube and hoghlights seem to be rotating in wrong direction. as Sebavan said adding material.invertNormalMapY = true solves the problem and higlight rorate in proper direction. So, the conclusion is: -Texture file with normal/height map in tutorial playground should be reedited with inverted changed Y part of normals. OR - material.invertNormalMapY = true should be added to playground of paralax tutorial But as i said earlier it is not a big deal ( not real bug or something),
  14. shadowGenerator self shadows

    Do you think are there any chances to improve that with new features of webgl2 ?
  15. parallax mapping, directional light bug

    Thanks, it solves issue for now, I need to do more test on project i am working on, to see if it works with more complicated scene. That texture and normal map are exactly same files as in the official babylon tutorial on parallax mapping topic , so i assumed those files to be the most ok as possible. https://doc.babylonjs.com/tutorials/Using_parallax_mapping So maybe file in tutorial is wrong? It still doesn't explain inconsistency of front vs back face lighting, but it is not as big problem in my case. But in case of switched backface culling CW vs CCW, or even worse when mixing CW and CCW faces while disabling backface culling, it may be an issue.