Announcement

Collapse
No announcement yet.

Add PreviousLocalToWorld to material editor.

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

  • replied
    Object being static kinda implies that point number two from the list above is not met, so it won't constitute a problem.

    Leave a comment:


  • replied
    so indeed it only affects moving objects. or is there any reason to change the object's local to world transform on a static object?

    btw enabling 'Accurate Velocities for Vertex Deformation' in the project settings fixed the bad ghosting on my static spinning grass. of course it doesn't help with the movable cube though (but for now I have no need for movable objects requiring RotateAboutAxis)

    Leave a comment:


  • replied
    For the issue to be present, all of the following has to be true:

    1) You are using WPO(Velocity output is obviously enabled)
    2) The object's local to world transform changes over time.
    3) In your WPO calculations you are relying on local transform(read it, on any nodes, that are not properly substituted for previous frame versions).



    Leave a comment:


  • replied
    ok something with alpha makes it really evident when using TAA

    Click image for larger version

Name:	spinninggrass.jpg
Views:	27
Size:	11.8 KB
ID:	1471232

    so, yeah

    Leave a comment:


  • replied
    yeah I figured as much


    in any case, is this an issue for non-moving actors?

    for example here I have the cube spinning really fast but I don't move the character.
    I have Motionblur and TAA enabled, though I had to disable DFAO otherwise it's really bad. but I don't get any ghosting or blurring, all I get are hard/jittery edges

    Click image for larger version

Name:	attachedcube3.jpg
Views:	28
Size:	34.8 KB
ID:	1471230

    Leave a comment:


  • replied
    Originally posted by Chosker View Post
    well I get the same issue even if I don't use a transform node

    Click image for larger version

Name:	rotaboutaxis.jpg
Views:	33
Size:	47.8 KB
ID:	1471216
    ^^ that's enough to produce the bad motionblur
    and of course unhooking WPO "gets rid of the issue"
    Your pivot position is also fed by a data, that has no replacement in previous frame, also providing erroneous calculations.

    Leave a comment:


  • replied


    wait. WPO unhooked now:

    Click image for larger version

Name:	attachedcube2.jpg
Views:	28
Size:	34.1 KB
ID:	1471219

    I had to rotate the camera really fast to get it though. I guess this is expected behavior
    but with the RotateAboutAxis, the result of my first screenshot is just from normal walking

    Leave a comment:


  • replied
    well I get the same issue even if I don't use a transform node

    Click image for larger version

Name:	rotaboutaxis.jpg
Views:	33
Size:	47.8 KB
ID:	1471216
    ^^ that's enough to produce the bad motionblur
    and of course unhooking WPO "gets rid of the issue"

    Leave a comment:


  • replied
    Originally posted by Chosker View Post
    so is this what you mean?

    Click image for larger version

Name:	attachedcube.jpg
Views:	28
Size:	79.9 KB
ID:	1471200
    Yes, exactly.

    Leave a comment:


  • replied
    so is this what you mean?

    Click image for larger version

Name:	attachedcube.jpg
Views:	28
Size:	79.9 KB
ID:	1471200

    Leave a comment:


  • replied
    Originally posted by Chosker View Post
    do you mean when using the Transform node with world->local? in this case I don't get if what you want is for something to be exposed to the material editor (I don't know where you'd use a PreviousLocalToWorld node in conjunction with RotateAboutAxis. previous frame switch perhaps?)... or if it's simply a bug that you'd like to see fixed (properly handling the previous frame internally)

    since Ive planned to try to use rotate about axis soon, I can probably have a look at the example you mention. though most likely I won't be able to solve anything and I'll just second you in requesting whatever needs to be requested
    TransformVector material expression with local as source or destination should automatically be compiled with previous frame transform, when being compiled for previous frame. It does not.

    It is not a bug, but lack of this feature is a complete showstopper for any local rotations in WPO, if world-local relation changes over time.

    Ideally, the change should be applied to all material expressions concerned, but just having the matrix accessible in pixel/vertexshaderparameters would be enough, since we have previous switch material expression.




    Last edited by Deathrey; 05-04-2018, 11:55 AM.

    Leave a comment:


  • replied
    do you mean when using the Transform node with world->local? in this case I don't get if what you want is for something to be exposed to the material editor (I don't know where you'd use a PreviousLocalToWorld node in conjunction with RotateAboutAxis. previous frame switch perhaps?)... or if it's simply a bug that you'd like to see fixed (properly handling the previous frame internally)

    since Ive planned to try to use rotate about axis soon, I can probably have a look at the example you mention. though most likely I won't be able to solve anything and I'll just second you in requesting whatever needs to be requested

    Leave a comment:


  • replied
    It is not about position. Position is being reconstructed totally fine. It is about a problem, when you are using world to local transform in WPO. It will be the same for previous and current frame. If you use that for rotation axis, the WPO for previous frame will be erroneous.

    The best way to illustrate is to attach any mesh to the camera(Motion blur enabled in pp), placed in front of it, and use WPO with rotate about axis around local axis, and put a constant into the angle. Final vertex positions with WPO for current and previous frame should match. But they don't and when camera is moved and rotated fast, the mesh will wobble insanely.

    Leave a comment:


  • replied
    check out DistanceFieldLightingPost.usf line 35. I'm not entirely sure but you might be able to track down how the params of the function are passed and so end up re-constructing the previous frame world position
    or maybe it's useless. only one way to find out!

    Leave a comment:


  • Add PreviousLocalToWorld to material editor.

    Lack of previous frame local to world matrix in material editor causes a ton of inconvenience, when working with world position offset.

    A typical example would be RotateAboutAxis material expression usage in WPO causing totally wrong velocity output and as a result, unwanted blurring/ghosting, which is commonly mistakenly attributed to TemporalAA.
Working...
X