styxxx

Members
  • Content Count

    27
  • Joined

  • Last visited

About styxxx

  • Rank
    Member

Contact Methods

  • Website URL
    https://www.styxxx.de

Profile Information

  • Gender
    Male
  • Location
    EU

Recent Profile Visitors

535 profile views
  1. styxxx

    Blank screenshots

    Hi, I'm getting blank screenshots only, meaning: a PNG with full transparency. The size is correct though. //Somewhere a scene is loaded var scene = null; BABYLON.SceneLoader.Load('', 'data/data.babylon', engine, function(newScene){ scene = newScene; // some stuff } //Some features like camera, lights are added... // Finally somwhere the render loop engine.runRenderLoop(function(){ scene.render(); }); // and then manually in the js console or via events the screenshot command is triggered: BABYLON.Tools.CreateScreenshot(scene.getEngine(),scene.activeCamera, {"precision": "1"}); I tried tracing the steps this function does in the babylon.tools.ts and entered the necessary commands into the javascript console: var screenshotCanvas; if (!screenshotCanvas) { screenshotCanvas = document.createElement('canvas'); } screenshotCanvas.width = 630; screenshotCanvas.height = 1366; // checked here and screenshotCanvas is set to '<canvas width=... height=... >' var renderContext = screenshotCanvas.getContext("2d"); renderContext.drawImage(engine.getRenderingCanvas(), 0, 0, 1366, 630); // engine.getRenderingCanvas() returns '<canvas class=".." id=".." width="1366" height="630" >' // it's the correct babylon canvas //Then I checked via renderContext.getImageData(400,300,200,1); // (random values) //if there was any value set to anything else then 0. But no, all the values are 0. For some reason there is no image drawn at renderContext.dawImage(). screenshotCanvas remains blank and I only receive the blank png engine is set (I also used scene.getEngine()), scene is set too (and has a lot of data). So is scene.activeCamera. There are no error messages. This looks like a bug. Although I can't get my head around it. Unfortunately I can't post the whole code since it's work related (and mostly done by a third party company). Would be way too large I guess. But as far as I can tell there's nothing that would explain it. The scene is used to render everything. Babylon v.2.5 is used. And chrome/chromium (the final product will use the chromium embedded framework to display the webgl animation within an native application)
  2. Hi, I want to get all the meshes that are visible within an rectangular area as seen from the camera and wonder what's the best solution to archive that. The user should be able to select an (2D) area and get all the meshes visible within it, like you can select multiple files in your file browser. I was thinking about: - calculating the 2D coordinates for every object and checking their values, or - using activeMeshes or something like that in some way without having to iterate though every object (getting the list without checking the 2D coordinates myself) Or is there any very easy way I didn't think yout? Maybe an already existing routine? Thanks
  3. styxxx

    Blender Exporter 5.0

    The blender file was created by myself (with Blender 2.77). I got the data as some different formats (.dae for example) and had to import them. So i don't think the .blend file is the reason. But I tried saving it to a new file to be sure and the same happened. Seems like during splitting the mesh (which is happening according to the log file) some variables get lost or unset.
  4. styxxx

    Blender Exporter 5.0

    Hi, I might have entcountered a bug. While exporting a scene I got from a third party the exporter crashes. Log file shows (I changed the mesh names due to privacy): First it causes the message "hasUnappliedTransforms" and then the "scale referenced before assignment" error,during the error message output. Both errors seem to be caused by trying to access the 'scale' variable before it was initialized? At least it looks like this. The mesh doesn't have unapplied transformations, I checked multiple times. So I guess there is something wrong with the variable when a mesh is splitted. Also the texture is deleted within blender after the exporter fails. I have to click "undo" to bring it back. I guess an exporter shouldn't do this. I didn't even know it was possible (the texture output file is just a black jpeg) edit: It works with the blender exporter 4.6.1 works. Well kind of. The textures are fine at first and get overwirrten during the export process an then are corrupted (or just black jpegs). And a lamp is added to the blender scene. But no error mesages and a babylon file is created. Also the mesh that causes the crash with 5.0.5 is completely exported. So it's a problem within the new exporter.
  5. Did this change? Because it's false on babylonjs-playground but always true in my example files (although I didn't set it), using v2.2.0. Like here (output on console): http://styxxx.de/temp/babylon/blender/blenderlights2.html Thanks
  6. Hi, thank you What about checkReadyOnEveryCallDidn't notice any effect by changing this option. I guess it still checks the state but when if not on every call? I also don't know why all my exported models have set the checkReadyOnEveryCall option in their babylon files. I haven't set anything in blender as far as I know. Or is this the standard behavior by the exporter? About the flat shading: When the babylon files contain "useFlatShading":true it's rendered exactly as the code generated models that weren't converted with convertToFlatShadedMesh (at least the cubes are). So shouldn't the ones made with createBox (and without convertToFlatShaededMesh) rendered as smooth as the imported ones?
  7. Ha! I found something: http://styxxx.de/temp/babylon/blender/blenderlights2.html Here's another example. This time I used the exact same values that were defined in the blender file of cube #3 for cube #1 (babylon-code). Now the first cube also doesn't respond as expected to option changs. So what's different? It's this: box_material.checkReadyOnlyOnce = true; Exported blender models always have this value defined in the blender file by the exporter. The default value for newly generated standardMaterials with js code is "false". I thought this value would be ignored anyway (I read it in some post) but I guess it changed. So this is responsible for most of the noticed strange behavior. I'm not sure if this is supposed to be this way. Using the wrong texture for a mesh looks like a bug no matter what's defined there. I'd expect no changes at all with this option set to true. But I'm not even sure what it really is about. And do I gain performance by setting it to false? There's stil something odd: The imported cube and the code-generated are still rendered differently. The specular effect and the lighting varies. #1 and #3 should look the same since the same values are set. So I guess the default values for some attributes are different for new standardMaterials and for materials of imported meshes? Or is this something about the normals? The "specular dot" is the most noticable. edit: Solved this too The culprit is: "useFlatShading":falseHow do I define this with code-generated models (like "createBox" and "new BABYLON.StandardMaterial)? Would still be awesome if a developer could take a look into the behavior when checkReadOnlyOnce is set to false to check if it is as supposed to be. After that I guess I can mark this problem as solved. edit: "Debug layer > Options > Textures" still has a weird effect with not disabling all textures as you would expect. Bump textures stay.
  8. Hello, you can ignore the post about the ship since the cube example is better The materials are different, I know. It wasn't primarily about the same color, but the effects you get when deactivating some options. While making this demo file I just also noticed that there might be differences (mostly with the specular effect). I'll take a closer look at it. Until then the isssue with the "eternal" light source and textures are more important. I guess something's happening while the meshes are imported that places them kind of "outside" the world. Can't describe it better. Try deactivating the light source in the example Should only affect the meshes that weren't imported. At least it's the case on my machine.
  9. Hi again, I made a demo file to show the effects I'm talking about http://styxxx.de/temp/babylon/blender/blenderlights.html (zip file to download: http://styxxx.de/temp/babylon/blender/blenderlights.zip) I created 6 boxes, the first two are made with BABYLON.Mesh.CreateBox, the other 4 are imported from ".babylon" files: 1. A box with a simple material, some diffuse, specular and a very dark emissive color (so it's still visible without light source). Created with BABYLON.Mesh.CreateBox. No textures. 2. Like the first box but with an additional diffuse and bump texture (the same file for both). The blender-generated babylon-files: 3. A box similar to box 1: just some colors (diffuse, specular, a little bit emissive). No texture. 4. A box with colors and additional diffuse texture 5. Colors + diffuse texture + bump texture 6. Colors + diffuse texture + bump texture + emissive texture The scene also has one light source. The babylon files don't have any specified. By clicking on any box the light intensity is set to a random value. So you can play around with it. Now let's take a look at the debug options or the console an the effects some actions have: Disable lights: The first two boxes are now dark, except for the emissive color. But the 4 imported boxes still receive some light. You can also see specular effects. The same effect can be created by using the console and manually setting scene.lightsEnabled to false. Or by disposing the light source with "scene.lights[0].dispose()." Change the intensity value or the color of the light source (with console): Works for all objects as expected as long as "scene.lightsEnabled" is true (or disabled in the debug menu). If not: nothing happens until you reactivate the light source. For example: "scene.lightsEnabled=false; scene.lights[0].intensity=0.1;" -> blender objects are still illuminated with intensity=1; (or whatever it was before) then enter "scene.lightsEnabled=true;" -> illumination drops to 0.1; debug layer: texture channels -> disable "Diffuse": The diffuse texture of the imported objects now change to the crater texture of box #2. Diffuse textures are still shown. debug layer: texture channels -> disable "bump": A smilar effect to the one before but this time the bump texture of the imported box #5 changes. But not for the last box: no changes here. debug layer: texure channels - > disable "emissive": Objects with an emissive texure (only box #6 in this example) start to glow like a christmas tree because also this time the texure seems to be swapped debug layer: options -> disable "textures": Only affects the non-imported meshes again.So as you can see imported meshes aren't treated like the others. While playing I also noticed differences on how the boxes are rendered in blender and in babylon. For example the bump maps are way more visible in babylon as if not only the normals are manipulated. But I'm not sure about that. Also the color values vary (are darker in babylon) and some options seem to be ignored like the blending mode for textures (mix, add, screen, multiply, etc). I guess that's simpley not exported by the babylon exporter. Also the value on how much the bump textures have influence doesn't seem to be included in the .babylon-file (or I'm just blind). [edit: The specular effects are also rendered differently on the imported boxes, aren't they?] So no big issues but while I'm at it I wanted to note too. Would be nice if someone took a look at it to confirm. Thanks.
  10. Sorry, wasn't meant to sound rude or demanding. Just wanted to be helpful by pointing out some probably bug. I created a playground, you'll need to enable the merge statement to see the effect. Since the meshes are rather simple it's not as severe as in "real life". Doesnt' have to bee 200 meshes, Tested it with firefox and chrome. Firefox just freezes and then reports that a script isn't working right. With chrome the tab crashes after all available memory on the machine is gone (edit: not all, but a lot; Just tested with more free mem). http://www.babylonjs-playground.com/#2EGQ6C#0 Just noticed that it also happens with just 2 objects. Doesn't need to be 200 like in the playground example.
  11. Hello, ah, I noticed that the merged instances are new meshes now. It works, but the result isn't an instance, it's a new mesh. So draw calls have increased. Interesting effect. Still BABYLON.Mesh.MergeMeshes shouldn't crash the whole browser/tab. The developers should fix it. Maybe something like "if parameter is not a mesh throw errror in console and do nothing". Seems like you can feed anything to such functions with various results. Makes it really hard finding some error in the own code. After doing more research I think it's more efficient to use lots of instances of smaller floor parts than to use one huge merged floor object since one large mesh has to be completely rendered/handled if just a small part is visibe. But with lots of small parts only those visible parts need to be calculated. Right?
  12. Hi, I have some ground tiles that I use. Currently I'm only using one "real" object and a lot of instances of it. But I'm wondering if it's more efficient to actually create a (bigger) merged mesh? Usually I'd assume the instances to be the better solution since it's a mesh with just a few vertices that will be referenced to. But while testing I noticed a higher fps after I merges some of the instances which seems to be possible. But merging instances strips the material. So how can I merge instances and keep it or reassign it afterwards? Does it even make sense or should I stick to the current solution? Also some interesting thing: merging only works with the code posted here https://github.com/BabylonJS/Babylon.js/wiki/How-to-merge-meshes Using BABYLON.Mesh.MergeMeshes skyrockets the memory consumption until the whole browser tab crashes. This is a bug and shouldn't happen. Even if you're not supposed to merge instances using gigabytes of memory and freezing the tab - of course without error message in the console - seems like a rather wrong reaction
  13. Yes, that's how it should be. But it doesn't behave this way, at least not always. I made a few more examples. http://www.babylonjs-playground.com/#JY2T5#11 Here I created a sphere, set the renderGroupId and then created some intances without touching the renderingGroupId. As you can see all the instances and the base sphere are now rendered behind the ground. This means that creating an instance resets the internal renderGroupId. http://www.babylonjs-playground.com/#JY2T5#12 Here I did the same. Except this time I changed the renderingGroupId of one of the instances after they were created with no effect. http://www.babylonjs-playground.com/#JY2T5#13 As before but this time I changed the rengerGroupId of the base sphere. Again no effect. http://www.babylonjs-playground.com/#JY2T5#14 Now I set the renderingGroupId in the loop for every instance. This time it works and all spheres have renderingGroupId=1, including the base sphere (I made a second ground to make it visible). But if I don't set it for every new instance it doesn't work at all: http://www.babylonjs-playground.com/#JY2T5#15 In this example I skipped sphere 3. Under other circumstances I noticed that only changing the last instance's renderingGroupId has any effect. Couldn't repdoduce it this time. Sometimes changing the base object's renderingGroupId worked as long as the new value was lower than before. Now it seems that I have to change all instances to the same value, different values has the same effect as setting them to 0: http://www.babylonjs-playground.com/#JY2T5#16 (this is exactly the same but I added console logging of the value: http://www.babylonjs-playground.com/#JY2T5#17) This doesn't seem straight. If the value can't be changed for single intances something like "instance.renderingGroupId=2" shouldn't change the variable. Maybe throw an error in the console? Creating new instances shouldn't reset the value for the base element. It isn't the case for other attributes. New instances should inherit the "parents" attributes (but this isn't the case for all, for example isPickable is also true regardless of the base element's value). Changing the base elements renderingGroupId should maybe influence the one of the instances as well. This is the case for "renderOverlay" where changing the base elements value changes the one for all instances, but changing the value of the instances alone has no effect.