Call for more developers: if you have patche(s) waiting for review, but also intended to become active as part of the module owner team, tell us! We will give highest priority to your work… would be a shame to have great new devs waiting.
It is a good time to get some of the cool features that are floating around here reviewed (Ton mentioned outliner improvements as one)- artists, give the patiently waiting patch devs a poke!
Theoretically, it shall become redundant:
The new BGE harmony branch is designed to provide inferred shading, and will hopefully bring with it soft shadows that run a lot faster, though this is all a work in progress
agoose
That’s funny, before posting I was just reading about Harmony again, but after seeing a “call for patches” I just couldn’t resist suggesting it. As you said, Harmony is still work in progress.
Why not use the already finished?
Moguri has stated that BGE_Harmony phase 1 and the Cucumber branch are about ready to be merged into Trunk, so it would be real nice if both of them could be merged in. Doing this will address a lot of feature requests and concerns from BGE users so it shouldn’t be kept waiting in my opinion.
@Alain:
Thanks for note, but i very doubt it practicaly useful. It screw original Cycles code a lot up to be completely unreadable, too many additional lines for very simple algorithm, it broke GPU render, very slow converging (i got fuzzy layered cube with cheating noise -free lighting as background light only after 28000 samples, it rediculous!. Of course it looks cool after all, but …). As it is, it more like concept for other developers and risky experimentators to show possibility and drawbacks. As I note in other thread, simple node that take as input distance from last bounce, and blend material with exp(-distance/sigma) formula and constant fog color will be easy, bug free and useful. No volume shadows, god rays of course, but it take near zero GPU/CPU time for nice fog/mist effect.
I think about patches to enhanced Display in 3Dview.(gradient background and wireframe color).
Looking to Module Owners lists (Actual owner of 3Dview is Ton who owns a lot of modules and is a busy guy.) and OpenGL bugtracker, I think there is a place for a 3DView dev.
I would like to see the API stabilized. As a python developer I feel like my work is underminded by the constant release of variations of the API that breaks my code. And these changes that break code could be avoided if the developers simply quit adding optional parameters in the middle of a existing working methods. Such as changes to template_list. This has been revised twice and each time new optional parameters were added in the middle of the variable list. IF you must add new optional parameters to an existing method add them to the end of the list so that backwards compatibility to existing scripts can be preserved.
There is no going back to 2.49 at this stage so 2.5/2.6 is our working daily program please don’t break it!
Are you guys poking the devs who are involved with these features? Just wishing here doesn’t mean a thing, it would be good to point coders with waiting patches to this particular bit of news.
Does anyone know if the PTEX direct texture painting feature was working in Onion? Better UV unwrap tools are great, but being able to add image maps to the model directly would be ideal.
ptex support was never fully finished, whilst you could paint in ptex… you couldnt render it (no BI support and no cycles support yet)… merging this in right now will just make people confused if you cant actually render anything with it.
true. But you need some of the base to be implemented first so that other part of the software can refer back to it. Unless if the developers are planning to merge a big chunk of code instead of gradual changes from base to the more complete features. Having a ptex code base can help any other developer to refer to the code if he/she wants to apply a patch to make it work with Cycles, for example. Another example is if someone wants to enhance the exporter with baked ptex texture.
Best thing to do would be to spawn off a new branch… integrating it into a trunk when its not fully finished is not a wise idea… could you imagine the influx of threads being started on BA about no rendering support for ptex?
Ptex is already in a separate branch. Agree that it’s not the right time to integrate into trunk without having support in BI or Cycles. There’s some argument to be made for export (i.e. Blender can provide Ptex painting and export.) However, I’d only really support inclusion under those circumstances if there’s some external renderer with Ptex support that has good integration with Blender.
So it would seem that all the Bishops are in agreement.
Thanks for the information. I haven’t been able to get Onion working at home, and couldn’t figure out the level of PTEX integration from the patch notes.
So from the sound of things, PTEX might be a target for this years GSoC, built on top of Onion and BMesh.
