User posts Ivan Lyubovnikov
05 April 2016 21:43
05 April 2016 19:27
Остался еще вопросик про ортогональную камеру + calc_ray. Не выходит пока.Так там camera_ray - это (0, -1, 0), потому что смотрим из камеры сверху вниз в направлении -Y. Это как раз правильно, и проверка не нужна.
Вот так, вроде, нормально работает (pline можно сразу в line_plane_intersect подавать):
function main_canvas_mousemove(e) {
if (_drag_mode)
if (_selected_obj) {
m_app.disable_camera_controls();
// calculate viewport coordinates
var cam = m_scenes.get_active_camera();
var x = m_mouse.get_coords_x(e);
var y = m_mouse.get_coords_y(e);
if (x >= 0 && y >= 0) {
x -= _obj_delta_xy[0];
y -= _obj_delta_xy[1];
// emit ray from the camera
var pline = m_cam.calc_ray(cam, x, y, _pline_tmp);
// calculate ray/floor_plane intersection point
var point = m_math.line_plane_intersect(FLOOR_PLANE_NORMAL, 0, pline, _vec3_tmp3);
// console.log(point);
if (!point)
console.log("no poit");
// if (camera_ray[1] < 0)
// console.log("camera_ray[1] < 0");
// do not process the parallel case and intersections behind the camera
if (point)
m_trans.set_translation_v(_selected_obj, point);
}
}
}
P.S. Шарик сейчас всегда сдвигается к центру курсора, в какой точке его ни возьми. Чтобы этого избежать, нужно запоминать смещение от центра шарика при mousedown, а при mousemove потом его учитывать - в демке cartoon_interior так и происходит.
05 April 2016 19:10
31 March 2016 12:19
So… I understand from your reply, that you assume that there is some kind of 1,5 GB memory restriction, imposed somehow by the web browser or the way WebGL works.
I don't hear about a certain number, it rather varies for different platforms/browsers. There is also a memory allocation issue. Roughly speaking, a browser should allocate a continuous block in memory for every datablock and it can fail if the memory is heavily fragmented. This gets worse for big scenes and big chunks of data.
It would be helpful for my case if it would be possible to reduce memory consumption for multiple instances of the sames mesh.
We're planning to implement instancing in the future, but only for particle systems.
Reducing the polygon count can definately be an option. Unfortunately, I don't think that there is a CAD conversion software that generates good quality models with low polygon counts. Also, I cannot go into the CAD models and delete thousand of nuts and bolts and other small details - this would not be time efficient.
You can try Blender's Decimate Modifier, but there is a warning in the description: "This is not usually used on meshes which have been created by modeling carefully and economically (where all vertices and faces are necessary to correctly define the shape)."
30 March 2016 12:47
Hmm, that's strange. 16gb of ram should be enough for such a big scene and you have a lot of memory available. But in my case, when I've reproduced this behavior, it was almost fully consumed.
We'll try to reduce the memory usage (there is a possibility for it), but I can't guarantee that this will be soon. Anyway, the scene should be optimized as much as possible. Limiting the size of a scene or reducing high-poly models is a good idea. I don't know if it suits you, because it can depend on a certain model or visualization requirements. Also, if you have many objects, they can be dynamically loaded/unloaded to control the memory consumption, but it requires some coding.
We'll try to reduce the memory usage (there is a possibility for it), but I can't guarantee that this will be soon. Anyway, the scene should be optimized as much as possible. Limiting the size of a scene or reducing high-poly models is a good idea. I don't know if it suits you, because it can depend on a certain model or visualization requirements. Also, if you have many objects, they can be dynamically loaded/unloaded to control the memory consumption, but it requires some coding.
30 March 2016 10:47
29 March 2016 11:24
29 March 2016 11:17
Hi! It depends on system specs. I've tested this scene on a Mac with Intel HD Graphics 3000 (while you have Intel(R) HD Graphics 4600 as it's seen from the log) and it works. A heavier scene will cause the same error on a more powerful system. This is probably a memory issue. It's well explained here: WebGL scene does't render because of lost context. So, I suggest you to check the memory usage to find out exactly what's going on.
24 March 2016 19:19
Могу ли я использовать свою структуру каталогов, работая с менеджером проектов в SDK?Да, но с некоторыми ограничениями. Если вы планируете пользоваться функциями менеджера, например, компиляцией или реэкспортом файлов, то придется либо следовать структуре по умолчанию, либо прописывать измененные пути в конфигурационном файле проекта (.b4w_project).
По умолчанию проект имеет такую структуру: структура проекта. Dev-версия лежит в SDK/apps_dev/myproject. JS, CSS, изображения и прочие файлы можно располагать как угодно. Путь к главному html-файлу должен быть прописан в параметре "apps" конфига. Blend-файлы и ресурсы (текстуры, звуки, …) находятся по умолчанию в SDK/Blender/myproject и SDK/deploy/assets/myproject соответственно. Пути к ним должны быть прописаны в параметрах "assets_dirs" и "blend_dirs" конфига. Параметр "build_dir" отвечает за путь к собранной версии проекта. Его также можно поменять, если понадобится.
Мы добавим в будущем в документацию описание настроек .b4w_project файла, и, наверное, распишем особенности структуры каталогов более подробно.