This script produces a very simple mover/agent/particle that randomly travels within two-dimensional bounds.
I think that it used to work great back in Rhino 5, but seems very laggy in version 6. The mover seems to slow down when approaching the scene centre (?) and the other GH components start to recompute like crazy. There is nothing particular evaluated in this region though.
import Rhino.Geometry as rg
import Grasshopper as gh
import random
import math
class Mover:
def __init__(self, pos, vel):
"""Inits this mover."""
self.pos = pos
self.vel = self.contruct_random_vector3d()
def update(self):
"""Updates this mover."""
self.check_bounds()
self.pos += self.vel
def contruct_random_vector3d(self):
"""Returns a random three-dimensional unit vector."""
vec = rg.Vector3d.YAxis
angles = [math.radians(a) for a in range(15, 345+1, 30)]
angle = random.choice(angles)
vec.Rotate(angle, rg.Vector3d.ZAxis)
return vec
def check_bounds(self):
next_pos = self.pos + self.vel
if next_pos.X > 100 or next_pos.X < -100:
self.vel *= -1
if next_pos.Y > 100 or next_pos.Y < -100:
self.vel *= -1
###############################################################################
def update_component():
"""Updates this component, similar to using a Grasshopper timer."""
def call_back(e):
ghenv.Component.ExpireSolution(False)
# Get this Grasshopper document
gh_doc = ghenv.Component.OnPingDocument()
# Schedule this component to expire
gh_doc.ScheduleSolution(1, gh.Kernel.GH_Document.GH_ScheduleDelegate(call_back))
###############################################################################
if Run:
mv.update()
a = mv.pos
b = mv.vel
update_component()
else:
mv = Mover(Position, Velocity)
Is there any issue with the update_component function in Grasshopper 1.x?
Or am I simply overlooking something?
Afraid not, but I imagine this has more to do with all the changes to the rendering pipeline in Rhino 6. In general, I too have been feeling like Rhino 6 sometimes feel more sluggish when opening older Grasshopper files. Especially dynamic ones such as your example (and Kangaroo ones). It might also be related to Rhino now supporting high resolution screen perhaps
Thanks, Anders. It’s weird how it’s switching from running fluently to sluggishly, mainly when approaching the origin, although the iteration-based processing stays exactly the same.
Could you please test the file on your system and check whether you encounter the same behaviour?
I just did, and though it’s slightly more sluggish in Rhino 6, it’s not to the same degree as what you’re seeing. Could it be the anti-aliasing that occurs when your agent goes into the grid that causes the lag?
Here’s the definition running on my system. There is no discernible lag from anti-aliasing (I even turn it off at one point), but oddly if I pan (at around 30 seconds in), the movement speeds up:
I assume this has something to do with dynamic redraw settings and using the OpenGl pipeline. If I set the display pipeline to not use OpenGl (i.e. Windows), the movement speed seems to be consistent when panning.
I’ve also noticed that there is no lag, when either the Grid, Grid Axes, or World Axes are turned on. However, the sluggish behaviour returns, when all three are active.
Panning also speeds up the “simulation” for me.
I’m using Rhino for Mac which uses OpenGL by default, with antialiasing set to 4x. There’s no way to turn this off.
Also @dan might be interested to take a look at this!
