Hi, sorry for the late response. The current OBJ code is just standing in until something more thought-out is written. If you come up with something more functional, that would be fantastic.
Euclid is currently lacking some fundamental structures that OBJ requires (e.g., triangles!), so you'd have a fair bit of work to add in making it work nicely. Be great if you could pull it off though. All the best, Alex. [EMAIL PROTECTED] wrote: >I'm experimenting with building a 3D app with Pyglet, and I'd like to >poll the crowd on a situation I find myself in. > >I'm using the OBJ code to render 3D objects, and the Euclid code to >manage some 3D information (a selection line generated using >gluUnProject, basically.) The problem is, the OBJ code doesn't manage >it's 3D information as Euclid objects, so for intersections etc. I'm >wondering the best way to bridge the gap. Should I: > >(a) modify OBJ to use Euclid objects, >(b) subclass OBJ to use Euclid objects, >(c) build a layer between the two to convert the OBJ data to Euclid so >I can use it, or >(d) something else. > >(a) involves making the OBJ code dependent on Euclid - is that a >problem? (b) and (c) make everything more complicated by adding more >classes. Which way is more inline with Pyglet's overall philosophy? > > >Thanks, > >Simon. > > >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
