YES! As I was typing my last email I was considering breaking it down explicitly like that, but decided to be vague instead.
pyglet_core (gl, window, canvas, no dependencies) pyglet_utils (event, clock, no dependencies) pyglet_media (media) pyglet_graphics (graphics) pyglet_drawing (sprite, text) pyglet_assets (resource, image) pyglet_input pyglet_transforms?? pyglet_models?? And then tie it all together with the pyglet superpackage, which has pyglet.app. You could also split the maintainer responsibility up across modules, version them separately, and have clear API touch points between them. They could remain in the same repo to keep things simple. The docs could be unified, or split up and linked using intersphinx, with the high level guides living in the main pyglet repo. (Reading back over this paragraph, though, that seems like too much overhead for the number of people on this project.) The split would solve a problem I had recently: if you want to use pyglet just for audio (in this case I was doing my graphics with BearLibTerminal), you have to do some pyglet.options voodoo. I'd rather just import pyglet_audio. It's the nicest way to do audio in Python by far. On Wednesday, June 7, 2017 at 10:11:26 AM UTC-7, swiftcoder wrote: > > Yeah, that's fair. Maybe it's time that pyglet became a collection of > libraries. > > On the other hand, we do need to overhaul pyglet itself to provide all the > modern OpenGL primitives. And those primitives aren't very useful to > newcomers without a high-level abstraction over models/scenes... > > Maybe go the other direction. Produce a pyglet-core with just the OpenGL > primitives, and make pyglet itself a meta-package over pyglet-core, > pyglet-scene, etc? > On Wed, Jun 7, 2017 at 09:07, Steve Johnson <[email protected] > <javascript:>> wrote: > >> I question the idea of including any of this stuff in pyglet. It is >> already a large library. >> >> Why not start by creating a third party module, letting it stabilize on >> its own, and rolling it into pyglet when it has proved its usefulness and >> quality? >> >> Honestly, if I were designing pyglet from scratch, I would create four >> separate libraries. Dependency management and app packaging in the Python >> ecosystem are not as hard as they used to be. >> >> On Wednesday, June 7, 2017 at 8:29:11 AM UTC-7, swiftcoder wrote: >> >>> Gltf would be a natural choice, in many ways: >>> >>> https://github.com/KhronosGroup/glTF >>> >>> It's an open interchange format, with some degree of tool support (and >>> very easy to write converters for). >>> >> On Wed, Jun 7, 2017 at 08:08, DR0ID <[email protected]> wrote: >>> >> On 07.06.2017 05:29, Benjamin Moran wrote: >>>> >>>> OK, loud and clear. I won't waste effort on transform methods. >>>> >>>> Another question is what types of codecs we should try to include other >>>> than obj, and who wants to write them? :) >>>> >>>> >>>> >>>> >>>> On Wednesday, June 7, 2017 at 10:34:31 AM UTC+9, Richard Jones wrote: >>>>> >>>>> There absolutely has to be a default vertex and fragment shader with >>>>> this implementation, yep. >>>>> >>>>> On 7 June 2017 at 11:19, Tristam MacDonald <[email protected]> wrote: >>>>> >>>>>> I think it's going to end up actively harmful. >>>>>> >>>>>> We need to give them the tools to do GPU transforms anyway (a class >>>>>> for placing models in the scene, default uniforms for the transform >>>>>> matrices, and a default vertex shader), at which point having methods to >>>>>> also pre-transform models on the CPU are redundant and/or confusing. >>>>>> >>>>>> On Tue, Jun 6, 2017 at 18:12, Benjamin Moran <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thanks for your feedback Tristam. I actually do agree with both of >>>>>>> you guys that this is GPU/shader territory. >>>>>>> >>>>>>> I am mainly looking at it from the viewpoint of a user thats using >>>>>>> Pyglet 1.3, and has little or no OpenGL knowledge. >>>>>>> For example, I have a little side-scrolling shoot-em-up game I made >>>>>>> to play around with projection and "2.5D" style side scrolling. Lets >>>>>>> say I >>>>>>> have a single asteroid model that I want to place in the background at >>>>>>> various random positions and rotations. Having a few transform methods >>>>>>> would let you randomly place them at runtime without needing to create >>>>>>> a >>>>>>> full scene in an editor. >>>>>>> >>>>>>> That's basically it. Do you think it would harmful to include >>>>>>> transform methods, in the sense that we would be giving users tools >>>>>>> that >>>>>>> they probably shouldn't really be using anyway? >>>>>>> >>>>>>> >>>>>>> On Tuesday, June 6, 2017 at 11:45:13 PM UTC+9, swiftcoder wrote: >>>>>>> >>>>>>>> I'm not sure it's worthwhile to include *at all*. What's the >>>>>>>> advantage of doing that, versus transforming the model on the GPU? >>>>>>>> >>>>>>>> Matrix * vector operations in the vertex shader are really cheap, >>>>>>>> and most programs are limited by the fragment shader performance. >>>>>>>> >>>>>>>> The only case where this might be a win is if you are assembling a >>>>>>>> level from singular geometries at runtime. Which seems a vanishingly >>>>>>>> unlikely case - generally you would assemble static elements in your >>>>>>>> editor, and then add multiple copies of props, etc at runtime. >>>>>>>> >>>>>>> On Tue, Jun 6, 2017 at 00:29, Benjamin Moran <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>>> ISTM that gross operations on the model (transformations on all >>>>>>>>>> vertices like the translation - I think that's what you mean by >>>>>>>>>> "shifting >>>>>>>>>> the model") should be handled entirely by a shader, and no actual >>>>>>>>>> vertex >>>>>>>>>> data manipulation, since setting the shader variable will be >>>>>>>>>> infinitely >>>>>>>>>> faster. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Richard >>>>>>>>>> >>>>>>>>>> Yes, sorry, I do mean translation. And you're absolutely right >>>>>>>>> that it's silly to do these types of transformations on the CPU in a >>>>>>>>> realtime application. >>>>>>>>> I was mainly thinking that it's useful to have transform methods >>>>>>>>> to reposition static objects in the scene when you first load them. >>>>>>>>> I think the only possibilities are passing arguments to the >>>>>>>>> pyglet.model.load function, or doing it right after loading. If you >>>>>>>>> do it >>>>>>>>> after loading, the following three methods should cover most bases: >>>>>>>>> Model.update(x, y, z) # Translate on a specific axis. >>>>>>>>> Model.scale(1.0) # Rescale the entire model. >>>>>>>>> Model.rotate(x, y, z) # Rotate along one or more axis. >>>>>>>>> >>>>>>>>> This would come with a big fat warning about not doing this every >>>>>>>>> frame, and of course using shaders is going to be necessary for most >>>>>>>>> things. >>>>>>>>> Does that sound reasonable? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "pyglet-users" group. >>>>>>>>> >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>> >>>>>>>> >>>>>>>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "pyglet-users" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "pyglet-users" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "pyglet-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> Hi there >>>> >>>> Not sure if you would like an external dependency or not, but there is >>>> assimp, see >>>> >>>> http://www.assimp.org/index.html >>>> >>>> It loads various formats to the same structure so the code will only >>>> have to worry about one format internally (I haven't used it yet, but >>>> probably will try it out in future). >>>> >>>> And I don't see the point to write your own codecs if some one else >>>> already has gone through the trouble making such a library. >>>> >>>> But sure, pyglet could focus on just one or few formats and that would >>>> be probably enough (since there are other ways to convert a model to the >>>> supported format). I would like a format where one can define bones and >>>> animations too. But that is just my wish. >>>> >>>> Keep up the good work. >>>> >>>> ~DR0ID >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "pyglet-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "pyglet-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/pyglet-users. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
