Announcement

Collapse
No announcement yet.

Auto Instancing vs ISM comparison (4.24)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by Ale_32 View Post
    Hey Slavq, here is the reply I got:



    So yeah, ISM is still a better option because of dynamic shadows.
    Thank you, that's good to know.
    ... Well, let's wait for Nanite

    Leave a comment:


  • replied
    Hey Slavq, here is the reply I got:

    Static meshes are instanced for cascaded shadow maps, used by directional lights. [...]
    There is no plan to implement it for the other types of shadow currently, but it would be doable.
    So yeah, ISM is still a better option because of dynamic shadows.

    Leave a comment:


  • replied
    Yeah, I've asked that to the UDN, I'll let you know if I can get an answer.

    Leave a comment:


  • replied
    Interesting, thanks for the info.

    I wonder if this is a bug or a limitation of the auto instancing tech.

    Leave a comment:


  • replied
    Originally posted by Slavq View Post
    When I first heard about auto instancing, I was hoping to e.g. be able to use blueprint actors for each building system placeable part, since that would be much easier - but it looks like we still need to use created/detected ISM or HISM component with the same mesh and add meshes as instances.

    Well, at least it helps with moving/physics objects so that's good
    As shown you in my post above, I get the same results from auto instancing and ISM only at the moment I disable shadows. Otherwise, the auto instancing will not merge the calls of the shadow depths, but ISM does.

    Leave a comment:


  • replied
    I'd like to revive this post, since today I've found that dynamic instancing doesn't really merge the draw calls when doing the shadow depths pass.

    I've tried with Unreal 4.25.1 creating a scene with 10 spheres (tried both with actors and static meshes), and then I have compared this with 10 cones spawned using an ISM.

    The shadow depths of the spheres:
    Click image for larger version

Name:	DynamicInstancingShadowDepths.png
Views:	472
Size:	121.4 KB
ID:	1783412
    The shadow depths of the cones with ISM:
    Click image for larger version

Name:	ISMShadowDepths.png
Views:	425
Size:	109.0 KB
ID:	1783413
    Last edited by Ale_32; 07-02-2020, 07:11 AM.

    Leave a comment:


  • replied
    When I first heard about auto instancing, I was hoping to e.g. be able to use blueprint actors for each building system placeable part, since that would be much easier - but it looks like we still need to use created/detected ISM or HISM component with the same mesh and add meshes as instances.

    Well, at least it helps with moving/physics objects so that's good

    Leave a comment:


  • started a topic Auto Instancing vs ISM comparison (4.24)

    Auto Instancing vs ISM comparison (4.24)

    Here's a simple comparison of 2222 spheres, one scene as instances of Instanced Static Mesh, second scene as blueprint actors with Static Mesh Component: https://i.imgur.com/3UVYQh0.png
    Auto Instancing is turned on (checked the console command and changed the directional light Mobility, as there's still a bug where auto instancing doesn't work before we change light mobility).

    ~1.2ms with ISM vs ~5.3ms with static mesh components with auto instancing.

    It seems that for scene optimization, we still need to use the ISM or HISM. For example, for an in game building systems. That's always quite cumbersome, since we need to operate on the instanced component and switch instances to blueprint actors counterparts when needed, and back, instead of just having a ready-to-use actors.

    I wonder what's the best use case scenario for auto instancing...? I guess that it is really useful in cases where we can't use ISM or HISM for some reasons...? For example, for many mesh actors with active physics simulation?
Working...
X