Sounds like implicit endorsement of option (a). :) And I'm happy to try hacking some rudimentary triangle support into Euclid on the way.
On Mar 11, 8:45 pm, Alex Holkner <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
