d954mas
November 25, 2023, 8:35am
6
I have some issues that i liked you to fix. So i show them again)
Please look at them, if you fixed them it will make me happy and games better)
1)Profiler currently disabled in the HTML5 build
New profiler is cool, but we need profiler in web to make performance games.
2)Frustum culling call when it not needed
Frustim culling can be better.
3)Change and get shape sizes, positions in runtime. You show this feature in roadmap
4)Gpu skinning
Low priority for me.Defold Mesh Binary can be used as workaround.
5)Render batch world for multiple render of same objects
SKINNING ANIMATION
1)81 enemy no shadow
render batch world:6.500-7.000
2)81 enemy shadow
render batch world:12.500-13.500
NO SKELET
3)81 enemy no shadow
render batch world:2.500-3.000
4)81 enemy shadow
render batch world:5.500-6.800
Looks like render batch world make same work twice when draw shadow.RenderBatchWorld do same work for every draw. For example when i draw same model multiple times per frame. Mb you can add some kind of cache?
RenderBatchWorld call for every model.
printf(" "); OutputVector4(mat.getRow(3));
}
static void OutputTransform(const dmTransform::Transform& transform)
{
printf("t: %f, %f, %f \n", transform.GetTranslation().getX(), transform.GetTranslation().getY(), transform.GetTranslation().getZ());
printf("r: %f, %f, %f, %f \n", transform.GetRotation().getX(), transform.GetRotation().getY(), transform.GetRotation().getZ(), transform.GetRotation().getW());
printf("s: %f, %f, %f \n", transform.GetScale().getX(), transform.GetScale().getY(), transform.GetScale().getZ());
}
#endif
static inline void RenderBatchWorldVS(ModelWorld* world, dmRender::HMaterial material, dmRender::HRenderContext render_context, dmRender::RenderListEntry *buf, uint32_t* begin, uint32_t* end)
{
DM_PROFILE("RenderBatchWorld");
uint32_t vertex_count = 0;
uint32_t index_count = 0;
uint32_t batchIndex = buf[*begin].m_MinorOrder;
for (uint32_t *i=begin;i!=end;i++)
{
const MeshRenderItem* render_item = (MeshRenderItem*) buf[*i].m_UserData;
Model go in rig and cound array of vertices
vb_end = dmRig::GenerateVertexData(rig_context, c->m_RigInstance, render_item->m_Mesh, world_matrix, vb_end);
Here you count matrices use 4 bones.
in_v.setX(*positions++);
in_v.setY(*positions++);
in_v.setZ(*positions++);
in_v.setW(1.0f);
Vector4 out_p(0.0f, 0.0f, 0.0f, 0.0f);
const uint32_t bi_offset = i * 4;
const uint32_t* bone_indices = &indices[bi_offset];
const float* bone_weights = &weights[bi_offset];
if(bone_weights[0])
{
out_p += pose_matrices[bone_indices[0]] * in_v * bone_weights[0];
if(bone_weights[1])
{
out_p += pose_matrices[bone_indices[1]] * in_v * bone_weights[1];
if(bone_weights[2])
{
out_p += pose_matrices[bone_indices[2]] * in_v * bone_weights[2];
if(bone_weights[3])
{
6)Editor performance and usability for 3d scenes.
For now editor is slow if scene is big. Also big in my cases is like my world in game with 4 areas and hundread of objects. So for now i use blender because it hard to make 3d scene in editor.
opened 03:12PM - 25 May 23 UTC
bug
editor
performance
**Describe the bug (REQUIRED)**
Editor is very slow when collection have a lot … of collision shapes
**To Reproduce (REQUIRED)**
Test project with 32 chunks.
[ManyCollisionsShapes.zip](https://github.com/defold/defold/files/11566459/ManyCollisionsShapes.zip)
https://github.com/defold/defold/assets/2655263/396faa77-6af5-4119-bd9d-54431a7b3113
When i have 256 chunks it is impossible to use editor.
**Expected behavior (REQUIRED)**
Editor worked fast with a lot of collision shapes
**Defold version (REQUIRED):**
- Version 1.4.6
**Platforms (REQUIRED):**
Editor
Is wasd camera movement already in editor?
Here’s another teaser for WASD camera movement that I’ve been fiddling with today:
Very early work, but something like this would be nice for previewing 3D content!
7)Store the meta data within the .buffer format
Need it for aabb for meshes
8)Debug draw native api
In this game i use draw_line for some chunks debug and pathfinding debug.
I think we need a new API for this kind of thing. There’s an increasing amount of extensions that have a need to draw debug info at runtime.
I think we need a new API for this kind of thing. There’s an increasing amount of extensions that have a need to draw debug info at runtime.
6 Likes