It wouldn’t be possible as in “we would need to rewrite the shaderGenerator”?
No, it conceptually can’t work with the concept of a ShaderGenerator as we have it now.
Well yeah, what do you think I mean by a rewrite?
Anyway, if I were to make a replacement for a shader generator for my project, how (diffently) would you suggest to make it then?
A system that divides up all the required behaviour into individual components, and has a system to hook up all the different components together, and a way to specify how the results of different components blend together.
Then you can let each component generate their, and generate the glue code for the output of those components.
Perhaps an illustration will help explain the concept:
blender.org/typo3temp/pics/923052fa19.png
This is also the approach we might take with Panda 2 - ability to override behaviour by simply overriding the shader code for a certain component, or adding another component and specifying how it blends in with the existing default components.
So simply rewriting ShaderGenerator won’t do the trick - it’d be turned into a whole conceptually different system.
Like this: blueprints.launchpad.net/panda3 … -generator
github.com/Craig-Macomber/Panda … -Generator
It does already work, but its not feature complete.
Note: the thing RDB linked is a fine approach for single output fragment shaders, and possibly as part of a more complete system, but I don’t really see that approach as being sufficient by itself.
I really dont like how the bloom filter works now. It affects everything by default and everything is just too bright. You can have a black glow texture on every single model you dont want to be affected by it, but usually their amount is greater than the models that are glowing, why not have it the opposite? Not have a model glow unless it has a glow texture? Or at least allow to set it to behave like that? The way you’ll do it now is have a blank (black) texture on every single model that shouldn’t glow. Thats not very nice.
You can do it with a material no need for a texture… and maybe with some options of the bloom fillter…the docs on that are a bit poor.
I’d have a request on pview to make it support common filters (or just bloom for glow).
um, what?
Gloss or glow? Glow doesnt seem to depend on the Emissive value of the material.
‘maybe’?
I didn’t find anything: panda3d.org/reference/python … monFilters
Is this offer still standing?
I’ve been following the Panda project for some time, and I am thinking of implementing some sort of editor tool over the summer. I guess that doesn’t really count as an extension… but I’m definitely interested in finding out how P3D can be improved.
Josh is no longer involved with the Panda team, so no, at least not from Josh’s offer. But there are others of us who are also interested in helping you to become a Panda developer. We may not have as much time to offer as Josh was offering, but we’d still like to do what we can to help you get started.
Note that there are multiple competing projects to produce a general editor of some sort, and people seem to have different ideas as to precisely what that means. My personal favorite editor project can be found in direct/src/leveleditor.
David
That’s too bad! He’s still with CMU, right?
And yeah, I saw some of the ideas; I was thinking more of an… object or asset editor.
I guess this is already largely covered by tools like Maya and so on, but I had some ideas on how to make it more like a ‘RAD’ tool rather than the current slower process.
But anyways, that was just one idea.
I mean, some other ideas that come to mind – silly or otherwise – are multithreading/voxel graphics, gravity (e.g., how can zero-g be handled), and so on.
Do keep in mind that threading is supported through an interface much like Python’s threading module (found here)
(that is of course, if that’s what you meant by multithreading)
Hope this helps,
~powerpup118
Is it possible to add to pdeploy the option to make a version of a Linux application which includes the needed libraries (i.e. not a deb file, but a compressed file with the necessary stuff - with some exceptions, like glibc)?
I was reading this post (but the entire thread is interesting, because it covers the Linux deployment), and this post answers to some doubts about the previous one; this is an article which covers the same subject, and the part 2 covers the specific part of executables.
The current pdeploy produces deb files, and this is the optimal solution when you can make assumptions about target systems. But, if you can’t make assumptions (because you want to deploy to many different systems), you’ll have some problems:
- http://www.gamedev.net/… section “The Problem”
- some distros could use different filesystem hierarchies, so you could have to provide different debs for different distros
- the user needs rights to install packages
- however you’re missing non-deb distros
Previous points imply that with this kind of deployment you’ll obtain:
- a simpler deployment (you’ve to maintain only one package (per-architecture))
- a more robust deployment (you provide the needed libraries and avoid bugs of specific versions of libraries installed by specific distros)
- a more complete deployment (at the moment you can target deb distros, but you would like to target even rpm distros, pacman distros, portage distros, …)
I’m not against the current pdeploy method, I only think that this addition could improve very much the Linux support of pdeploy. Thank you!
Syntax highlight for [ code ] in the forums please
You can easily use some javascript snippet in about every modern browser to achieve that. In opera its very easy, i used http://google-code-prettify.googlecode.com/svn/trunk/README.html.
And i agree that is too hacky, and i am all in for moving panda forums to some newer backend.
We need a way to get the handle of the main window, so we can pass it to library’s such as Tkinter.
A few more request after playing around with UDK.
It would be very nice to have height fog.
udn.epicgames.com/Three/HeightFog.html
I really like the exponential height fog.
It would also be very nice to have a material file format. Such a format would include textures for bump, glow, diffuse, ect. and also shaders and the like. With such a format we could write a very nice material editor.
Also it would be nice to include textures in the .egg file. This could be used instead of the material format.
And, while I am at it, it would be REALLY REALLY nice to have a drag-and-drop/real-time shader creator/editor.
I would be willing to help with the coding of any editors and such.
And I know most of this will not happen…
I think existing fogs dont work with the shadergenerator yet, wouldnt it be better to fix existing stuff before adding new?
As for a shader editor, Craig was working on one. He was also working on his own shader generator.
I don’t get the part about materials. In an egg file you can have materials defined just as textures. Moving that to a separate file has no sense to me. Just like putting textures in egg files - egg is a human-readable text file - a texture is an image (binary) file.
The idea is to include all textures, shaders, and the like in a single file.