Sure, but my point stands about needlessly adding new stuff to an already-big library when it would work 100% as well as a third party library.
On Wednesday, June 7, 2017 at 4:09:20 PM UTC-7, Richard Jones wrote: > > Careful, folks. Please don't kill off this actually very useful > contribution to pyglet by sidetracking it into a massive (unnecessary, > bordering on harmful in my opinion) refactoring. > > > Richard > > On 8 June 2017 at 03:36, Steve Johnson <[email protected] <javascript:>> > wrote: > >> 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]> 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]. >>>> 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.
