Any body has an idea if that is going to be possible or build in?
Claas
I don’t think someone is interested in it, because it will slow down every game extremely and baking the textures ist not so difficult.
The game would need to bake the textures in realtime, in the resolution that is necessary - not so easy, I think.
To use this only for Game would be short sighted.
A bake function is good when you know what you have but it is not that useful
when you want to quickly explore material properties for surface design.
Procedural textures is not used in the professional game developing (in 99.9%).
But of course Blender users needs it…
Strange… very strange. There is something I can not understand…
well they’re not used yet… but they will be…
The thing is that most of the procedural textures are actually 2d. Lightwave has displayed procedural textures in the GL view for 2 or three years… Cekuhnen is bang on the money that having them in the gl view would really help visualise results and speed workflow regardless of whether the final output will us them or not.
It actually needn’t be slow as the texture only needs to be calculated when a procedural is changed… obvioulsy the “resolution” for GL procedurals would need to be set somewhere, either as a global value or per procedural texture.
Endi, pro games don’t use them because of inconsistencies with graphics cards --> varying results and because you want to precalculate as much as possible (as i’m sure you’re aware). baking is just way more efficient for realtime.
The thing is though that good GLSL previews brought be Apricot are of use to all users, not just those using the game engine. I’m guessing Cekuhnen is one of those based on some of his other posts.
the potential for better and more immediate feedback that the GLSL improvements bring can really help you get a better result more quickly (what all PRO users want).
Lightwaves’ Fprime renderer springs to mind… giving instant feedback to almost any changein materials, lihghting, procedurals etc…
this means that it really is worthwhile to have stuff that might be really bad practise for a realtime game environment. the pros will still optimise for performance but rapid prototyping has to be the future…
that’s why the apricot team switched to blender game engins after all… because they didn’t want to wait for all the baking/preprocessing required to go to Crystal Space…
No, they’re not. All the procedurals in Blender are full 3D textures.
Stack a bunch of planes with transparency, you’ll see.
Martin
… Ahh. my bad!
Baking starts to look easier then;-)
Endi
you don’t think your view is narrow?
Mike
that is my point. Endi might think GLSL is only something for game design, which he works in
but that is not the end were this can be used, and Endi this is not only were it is used in the
industry either.
Game design is only a small section. Did you go to SIGGRPAH?
I saw more non-game design presentations with realtime texture and illumination systems.
In shaded view you can see somewhat the procedural when the vertex amount is high enough
which makes it useless.
The texture view should be independent of the mesh level.
We don’t need a 10 to 65k engine to have better control over textures we create.
Simple realtime preview with preview quality can be already enough without using
all the time the preview window which works half / half.
It is a good solution but does not address or allow quick changes in the scene from mesh
to lights and textures.
I would support the using of converting procedural textures to fast shading in the BGE because it’ll save a ton of file size when you use that instead of 50 different high res textures. The 3D view would also be good.
The makers of MapZone, I think, have a pro tool that allows procedural data from that tool to be used in the engine, it can really save file size.
I’m not a good graphics artist and would love this feature inside of blender just for fun reasons. Would for sure be a showpiece feature.
But a friend of mine is making graphics for several open source games. OpenTTD for example, which has prerendered graphics. Most of the time he is using procedurals for the textures and it would really speedup his workflow if he could preview the procedurals in the 3d view.
Would it really be that hard to implement live procedurals? Is there even a chance that someone from the developers will be interessted in implementing them or are the use cases not enough? Don’t know if this is only a minority which could take advantage of this…
I’m trying to figure out why someone would be against this. As realtime shading becomes more accessible (it’s just gonna happen, kids), more realtime media is bound to happen and to rely on shaders (which sort of blurs the line between procedurals and image-based). Second, it improves texturing workflow, and third, the feature definitely sells.
Ton
in his own presentation mentioned that the GLSL support is not only for gamers (mainly for this APricot project of course) but also from architects to rapid prototyping.
It seems he has some good goals for this.
which presentation do you mean? is it anywhere on the net?
I don’t think that anyone of the devs is against it, but they are on a crunch workflow to get everything wrapped up and add just what is required for the game.
After that, its all hands on deck for 2.50.
So its not a case of “against’” so much as “Just no time”
I think the real sad thing at the moment is that there are no moves to put some of this wonderfullness into trunk 
Think of it this way, if the GLSL never makes it to trunk then it completely defeats the notion of the Apricot Project showing off the capabilities of the BGE.
Ton would have to be on drugs to reject all the Apricot GLSL stuff.
It’ll get there eventually, just waiting for apricot to be over.
Martin
That’s good to hear, especially if what will happen is Apricot finishes, people drool over the special Apricot Blender version and then it’s all officially going into 2.50.
Just to note the BGE can still go on after Brecht and Campbell leave development of the BGE due to 2.50, Durian, ect… The BGE has Ben and Toonist has started further optimization of the BGE as of the end of Apricot.
I wouldn’t say “all”.
Some of the apricot changes were quick “hacks” to make a very specific thing work for them, so it won’t be a straight merge back from the branch.
The GLSL stuff is a sure thing though, don’t worry about that.
Martin