Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide and implement a strategy for adding and removing resources. #153

Open
rec opened this issue Jul 30, 2013 · 2 comments
Open

Decide and implement a strategy for adding and removing resources. #153

rec opened this issue Jul 30, 2013 · 2 comments
Assignees
Milestone

Comments

@rec
Copy link
Collaborator

rec commented Jul 30, 2013

See this thread: https://groups.google.com/forum/#!topic/pi3d/I0YCo9fd594

There's now a simple solution for Building...

but in general, pi3d doesn't really have a well-defined lifecycle of "things we keep track of" that lets you remove something and make sure for sure that all of its parts will stop rendering and that all its resources will be freed.

@ghost ghost assigned paddywwoof Jul 30, 2013
@paddywwoof
Copy link
Collaborator

Building is a bit of special case because it combines standard Shape objects with the special collision system. Generally everything that is displayed inherits from Shape so maybe we could add something to that class that registers itself in Display. There is already a facility for this in the Display.sprites list and Display holds lists of the glbuffer and texture objects so it might not require much else. Possible issues are to do with trailing/circular references stopping the del() or gc working and the 'clone' mechanism where multiple Shapes can share Buffers. Having said this the clean up process for Shapes is now pretty good but I suppose it might be useful sometimes to get a full list.

The other point is that it would be nice to have a method in Shape that could do collision detection so that Building could be significantly simplified. We already do this for the ElevationMap but it's less trivial for more complicated nets with lots of vertices. I might scout around for some ready made algorithms!

@rec
Copy link
Collaborator Author

rec commented Aug 31, 2013

Circular references are only an issue if there's an del method, but
registering your class with Display will keep the reference so your class
will never be deleted...

Remember that you can always use weak
referenceshttp://docs.python.org/2/library/weakref.html to
deal with the garbage collection issues - if you're careful!

On Sat, Aug 31, 2013 at 9:01 AM, paddywwoof [email protected]:

Building is a bit of special case because it combines standard Shape
objects with the special collision system. Generally everything that is
displayed inherits from Shape so maybe we could add something to that class
that registers itself in Display. There is already a facility for this in
the Display.sprites list and Display holds lists of the glbuffer and
texture objects so it might not require much else. Possible issues are to
do with trailing/circular references stopping the del() or gc working
and the 'clone' mechanism where multiple Shapes can share Buffers. Having
said this the clean up process for Shapes is now pretty good but I suppose
it might be useful sometimes to get a full list.

The other point is that it would be nice to have a method in Shape that
could do collision detection so that Building could be significantly
simplified. We already do this for the ElevationMap but it's less trivial
for more complicated nets with lots of vertices. I might scout around for
some ready made algorithms!


Reply to this email directly or view it on GitHubhttps://github.com//issues/153#issuecomment-23605875
.

 /t

http://radio.swirly.com - art music radio 24/7 366/1000

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants