Giter VIP home page Giter VIP logo

Comments (5)

MD485 avatar MD485 commented on August 11, 2024 2

See this is a complicated issue, because I actually really like Facepunch's implementation.

What's good about it?

If you're making a line in a game do you wanna have the control points as physical gameobjects in the world you can manipulate manually, or would you prefer to hard code a number and hope it looks right?

You wanna add triggers to the points so that something happens when you pass a checkpoint? You can do that.

You wanna make the line renderer flow into a door, then through an enemy, then into a window to show the player their path?
Not only can you do that, but none of those things need to be children of the renderer or have special properties allow that, and the line renderer will dynamically update as their positions do, something you'd have to do manually in Unity.

As someone who used unity a lot and is used to their implementation, and as a knee jerk reaction had the same thought process, I understand what you're saying, but I don't think this change is it.

But I can't network them!

Something else to consider is that LineRenderers I don't think are practially designed to be networked, the main reason being it's purely a visual component.

ModelRenderers I believe are written the same way, without any sync components, the expectation being that you don't network the ModelRenderers themselves, but instead network the scripts that manipulate them.

So what I should just give up?

Well, no I didn't say that.

LineRenderers I don't think should be directly networked, this feels strange, it's something visual that's ideally local to the client controlling them. Solutions should be made to manipulate local copies of line renderers as opposed to networking them.

I do like this implementation and think it should stay the default due to it's ease of use, flexibility and simplicity.

However part of the advantage of Unity's implementation is it's low overhead, and simple to manipulate through code.

So my personal suggestion would be to simply change this issue to:

Add a Vector3 LineRenderer

In terms of difficulty this would be trivial.
You take the code they have already, then do:
public List<GameObject> Points { get; set; } => public List<Vector3> Points { get; set; }

        IEnumerable<Vector3> enumerable = from x in Points
                                          where x.IsValid() && x.Active
                                          select x.Transform.Position;

=> IEnumerable<Vector3> enumerable = Points;

And boom, you're done:
image
Erm, whoops, err ...
IEnumerable<Vector3> enumerable = Points;
=> IEnumerable<Vector3> enumerable = Points.Select(x => Transform.Position + x);
Boom, you're done?
image

They'll have to add that bit of logic for Local vs Worldspace, but otherwise a pretty trivial code change.

A secondary advantage this allows for, possibly minor, code optimisations when rendering the line.
Because the _so's line is regenerated every OnPreRender, you can change that code to only run when the points list or GameTransform of the object is manipulated, as opposed to every frame(?).

This would mean adding SetPoints() and RemoveIndex(int index) and whatever else wrapper methods you would want for manipulating the points and making public List<Vector3> points; private, but depending on how things are implemented on the backend it's possible this could have some performance benefit,

from sbox-issues.

cmcskimming avatar cmcskimming commented on August 11, 2024 2

Garry's gotta switch it to vector 3 the game object points just don't make any sense, if you want to use game objects as your points for the sake of simplicity JUST MAKE A SCRIPT FOR IT. They shouldn't value ease of use for your specific use case over adaptability, not everybody wants to draw lines between game objects.

from sbox-issues.

chrisspieler avatar chrisspieler commented on August 11, 2024 2

I think it makes sense for the built in components to be as flexible as possible. Defining a position with a GameObject is far more flexible than just using a Vector3. Anyone is free to make a more efficient version of LineRenderer that uses only the exact data they need.

from sbox-issues.

MD485 avatar MD485 commented on August 11, 2024

Since we have Vector3s now as a part of the default LineRenderer, is it fair to consider this complete?
Although it is only in worldspace and there isn't a toggle for localspace unfortunately.

from sbox-issues.

ShadowBrian avatar ShadowBrian commented on August 11, 2024

Yeah I feel like this is closable now.

from sbox-issues.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.