Announcement

Collapse
No announcement yet.

Spline Decals?

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

  • replied
    Originally posted by Deathrey View Post

    No doubt, automatic is nice.
    But I'm not sharing a philosophy of If it can't be implemented universally and for every possible case, it should not be implemented at all.
    I don't share it either, but it just seems that epic does

    Leave a comment:


  • replied
    Originally posted by Maximum-Dev View Post
    Seems like even if you move the spline below landscape surface in cryengine it still projects to landscape surface above it. Cant we just have a spline decal projecting all along Z direction while affecting landscape only?
    There is no projection involved there, and whole thing operates roughly, as I outlined here.

    Leave a comment:


  • replied
    There's a bus simulator mod kit on the launcher now. Anyone had a look? Food for thought

    Leave a comment:


  • replied
    Originally posted by Maximum-Dev View Post
    Seems like even if you move the spline below landscape surface in cryengine it still projects to landscape surface above it. Cant we just have a spline decal projecting all along Z direction while affecting landscape only?
    Well it's pretty similar to using the Ddecals already in the engine. While I haven't checked or paid attention, they have a box of influence to them, so it would make sense for them to work from above or below the surface.

    Spline decals need to follow the same "box of influence" principle.

    Leave a comment:


  • replied
    Seems like even if you move the spline below landscape surface in cryengine it still projects to landscape surface above it. Cant we just have a spline decal projecting all along Z direction while affecting landscape only?

    Leave a comment:


  • replied
    Originally posted by Chosker View Post
    [/SIZE][/FONT][/COLOR][/LEFT]
    oh I prefer this to anything hardcoded any day but it's not what is friendly for me (as a tech artist), I just mean artist-friendly in a level designer sort of way.
    if the setup requires just copy-pasting a few nodes then there's no reason to not have it under the hood, but if those nodes need tweaking then it's likely that a level designer won't understand what needs to be done because a level designer doesn't necessarily know how to create complex materials or what even is WPO (and their materials might consist of an albedo and a normalmap hooked and that's it). in the end it's the level designer that will use the feature, and not every team has tech artist to set things up for them.

    I'm just going here by what I see as Epic's usual behavior in terms of tools usability. usually they try to go for something that "just works" or comes close to it (as with mesh decals' WPO) and ignore when the flawed use cases are uncovered (again as with mesh decals), in other cases where finetuning is more necessary they usually try to go further with editor-exposed variables.
    in this particular case I think they'd need to expose a variable in the "spline decal actor" that is passed into the shader, or maybe a variable in the material properties, but again I really don't expect Epic to make a specific WPO material node setup to be -required- for a feature like spline decals.
    of course this is all just speculation from me, but think I've seen enough of how Epic thinks around their tools to have an educated guess

    if the maximum vertical error can be figured out in 95+% of the cases, I would think they would just hardcode it in the shader. this is the "just works" case I mention above
    No doubt, automatic is nice.
    But I'm not sharing a philosophy of If it can't be implemented universally and for every possible case, it should not be implemented at all.

    Leave a comment:


  • replied
    Originally posted by Deathrey View Post
    Well, what you would call good enough then? One way or another, you need to do that. Not sure what would be not friendly in having WPO doing this for you. Even more to that, I would prefer this to anything hardcoded.
    oh I prefer this to anything hardcoded any day but it's not what is friendly for me (as a tech artist), I just mean artist-friendly in a level designer sort of way.
    if the setup requires just copy-pasting a few nodes then there's no reason to not have it under the hood, but if those nodes need tweaking then it's likely that a level designer won't understand what needs to be done because a level designer doesn't necessarily know how to create complex materials or what even is WPO (and their materials might consist of an albedo and a normalmap hooked and that's it). in the end it's the level designer that will use the feature, and not every team has tech artist to set things up for them.

    I'm just going here by what I see as Epic's usual behavior in terms of tools usability. usually they try to go for something that "just works" or comes close to it (as with mesh decals' WPO) and ignore when the flawed use cases are uncovered (again as with mesh decals), in other cases where finetuning is more necessary they usually try to go further with editor-exposed variables.
    in this particular case I think they'd need to expose a variable in the "spline decal actor" that is passed into the shader, or maybe a variable in the material properties, but again I really don't expect Epic to make a specific WPO material node setup to be -required- for a feature like spline decals.
    of course this is all just speculation from me, but think I've seen enough of how Epic thinks around their tools to have an educated guess

    Originally posted by Deathrey View Post
    You can calculate the exact amount you need to push the vertices up with distance, to account for maximum vertical error of landscape and always stay sufficiently, but not more than enough above the landscape at each lod level and transition regions.

    if the maximum vertical error can be figured out in 95+% of the cases, I would think they would just hardcode it in the shader. this is the "just works" case I mention above

    Leave a comment:


  • replied
    Originally posted by Chosker View Post
    [/SIZE][/FONT][/COLOR][/LEFT]
    oh you would still calculate UVs with distance to the center of the spline. by skipping the cutting you'd just have 'pieces' of polygons that would have the U coord lower than 0 and higher than 1 at each side.
    it's just a small suggestion in case anyone ventures into making this.
    I did get the point of your suggestion, but you did not get a point of mine.
    You will not have sufficiently good interpolation, if your UVs are defined only at landscape topology vertices. Interpolation is linear.

    Originally posted by Chosker View Post
    [/SIZE][/FONT][/COLOR][/LEFT]
    [LEFT][COLOR=#252C2F][FONT=Helvetica][SIZE=13px]
    requiring additional material nodes that push vertices towards the camera isn't the most friendly thing ever. emphasis on the -requiring- here.

    an example is how mesh decals get pushed towards the camera in the shader files (and has no manual control anywhere, unless you modify the shader yourself or add material nodes that counter this behavior). it's kinda obvious that Epic decided to just put it in the shader in order to have the feature working out of the box without requiring extra material nodes that wouldn't be artist-friendly
    Well, what you would call good enough then? One way or another, you need to do that. Not sure what would be not friendly in having WPO doing this for you. Even more to that, I would prefer this to anything hardcoded.

    You can calculate the exact amount you need to push the vertices up with distance, to account for maximum vertical error of landscape and always stay sufficiently, but not more than enough above the landscape at each lod level and transition regions.

    Surely you can add a ton of code to tie together landscape LODs and special category of mesh decal material, that would be automatically fed information about landscape LOD settings.
    That can be done and would be welcome, but bothering with that is never worth the effort just to make it artist friendly, considering that anyone several months familiar with the editor can do it and especially if you consider, that you can just eyeball the distance required.

    Leave a comment:


  • replied
    Originally posted by Deathrey View Post
    You need those vertices to support splinemesh UVs. Distance to the center of the spline, encoded in landscape only topology will not give UVs you'd want.

    Determining which landscape edges splinemesh triangle overlaps, and cutting triangle with every edge is not exactly the basic stuff, but isn't something far advanced either.
    oh you would still calculate UVs with distance to the center of the spline. by skipping the cutting you'd just have 'pieces' of polygons that would have the U coord lower than 0 and higher than 1 at each side.
    it's just a small suggestion in case anyone ventures into making this.
    [/QUOTE]


    Originally posted by Deathrey View Post
    Why not? What would be the problem with that?
    requiring additional material nodes that push vertices towards the camera isn't the most friendly thing ever. emphasis on the -requiring- here.

    an example is how mesh decals get pushed towards the camera in the shader files (and has no manual control anywhere, unless you modify the shader yourself or add material nodes that counter this behavior). it's kinda obvious that Epic decided to just put it in the shader in order to have the feature working out of the box without requiring extra material nodes that wouldn't be artist-friendly

    Leave a comment:


  • replied
    Originally posted by Chosker View Post
    actually I think just mimicking the landscape topology could be enough, and skipping the cuts related to the spline shape. you'd end up with more than you need but you could still get rid of it via material opacity based on UVs (distance from the center of the spline). it would simplify the process a lot I think, because guessing the vertex positions at the cuts gets tricky[/SIZE][/FONT][/COLOR][/LEFT]
    You need those vertices to support splinemesh UVs. Distance to the center of the spline, encoded in landscape only topology will not give UVs you'd want.

    Determining which landscape edges splinemesh triangle overlaps, and cutting triangle with every edge is not exactly the basic stuff, but isn't something far advanced either.



    Originally posted by Chosker View Post
    I don't think Epic would ever go for something like this though
    Why not? What would be the problem with that?

    Leave a comment:


  • replied
    Originally posted by Deathrey View Post
    Spline render mesh needs to be constructed in a such way, to contain vertices and edges from both splinemesh and landscape LOD0 beneath it.

    actually I think just mimicking the landscape topology could be enough, and skipping the cuts related to the spline shape. you'd end up with more than you need but you could still get rid of it via material opacity based on UVs (distance from the center of the spline). it would simplify the process a lot I think, because guessing the vertex positions at the cuts gets tricky
    Originally posted by Deathrey View Post
    Dealing with with pushing landscape splines upwards in the distance, to account for for landscape LOD morph should be done by users in decal material.

    I don't think Epic would ever go for something like this though

    Leave a comment:


  • replied


    Dropping by to mention, that the whole change, requested for more than a year in this thread is defined as follows:

    Spline render mesh needs to be constructed in a such way, to contain vertices and edges from both splinemesh and landscape LOD0 beneath it.
    A project spline to landscape button should be added.
    When the button is pressed, for every spline render mesh vertex, determine the corresponding landscape triangle, get Z positions of its 3 vertices, interpolate, depending on where render mesh vertex is located in relation to landscape triangle, considering XY only, and move spline render mesh vertex to the resulting height plus constant bias.

    Translucent sort priority is already there.
    Dealing with with pushing landscape splines upwards in the distance, to account for for landscape LOD morph should be done by users in decal material.

    That is pretty much it. Not that much of a work for one of the top requested features.
    Last edited by Deathrey; 06-15-2018, 06:56 PM.

    Leave a comment:


  • replied
    Still have to spend hours trying to line up road edges on curvy landscapes.

    Leave a comment:


  • replied
    Where can i vote for this as a feature?

    Leave a comment:


  • replied
    So pathetic

    Leave a comment:

Working...
X