Ivan Lyubovnikov

Hi,

We’ve managed to fix this issue. The fix will be available in the next Verge3D minor update which is planned next Monday.

Hi,

There’s no controls.dampingFactor setting but you can use the following properties to control the damping effect for different types of movement and for both mobile and desktop controls:

controls.rotateInertia = 0.1;
controls.rotateInertiaTouch = 0.1;
controls.panInertia = 0.1;
controls.zoomInertia = 0.1;
controls.zoomInertiaTouch = 0.1;

visual_logic.xml is only used in the Puzzles Editor for generating visual_logic.js, which is the file that’s actually used in the application.

So, if you want to change the files manually you definitely need to edit the .js file. Although, I’d suggest using the Puzzles Editor locally for that and then update both .xml and .js in the published version.

Hi,

We have not tried using AFrame in combination with Verge3D, but I think that there can be many issues if you try to integrate one into the other in a single 3d scene. Both AFrame and Verge3D have Threejs as a base, but they also both manage loading, creating and initializing a 3d scene on their own, so that’s the part there they conflict with each other. And I think there’s simply no easy access from Verge3D to an AFrame scene and vice versa, since one engine doesn’t “know” about the 3d scene and its objects that were created in the other engine.

But if you want to use AFrame to render a separate webgl scene then there shouldn’t be any problems with that. If by “user can create additionally” you mean custom puzzle plugins then I believe you can just load AFrame library and use its API inside a custom puzzle.

Hi,

Do you mean the visual_logic.xml file that’s used for Puzzles or some other xml file in your app?

Hi!

Generally, it depends on how complex are the materials that you want to optimize. Also, the performance gain can vary on different hardware.

If the materials are simple as you say, then it’s quite possible that you won’t get any noticeable difference. But on the other hand you have thousands of them, so… the only answer is to test that.

You can use the v3d performance profiler in your current project to check how much time the materials take to render. You can do that through the puzzle System->print_performance_info or just pasting this into the console: v3d.apps[0].printPerformanceInfo().

You’ll get various rendering info printed in the console, but the sections that are important in your case are “Materials and Shaders” and “Total Render Time”. If you aim at 60 fps then the total render time shouldn’t be higher than 16ms. Also, if it’s quite low (5-6ms) then there’s probably no point in optimizing at all.

Also, from “Materials and Shaders” you can see if there are any materials that take much longer time to render than others and therefore are a potential bottleneck.

Also, you can do this quick test:

v3d.apps[0].scene.traverse(function(obj) {
    obj.material = new v3d.MeshBasicMaterial({
        color: new v3d.Color(Math.random(), Math.random(), Math.random())
    });
});

– this replaces all materials in the scene with the Basic material with no textures (or you can do that only for materials you need to test performance of). If there’s no performance gain even when using Basic, then there won’t be any when using an optimized material with everything baked into a single texture.

Hope this helps!

Ah, I see. That’s weird because the snap puzzle shouldn’t change the far value. Can you provide a test example to reproduce this issue?

Hi! That’s probably because the standard element #v3d-container (which contains the 3d scene) is rendered above the buttons. That happens because it has the following CSS rules applied:

position: absolute;
z-index: 0;

To fix that you can just put the buttons right inside #v3d-container. Or, alternatively, leave them as is but add CSS rules like “position: relative; z-index: 1;” so they will be rendered above #v3d-container.