Multitexturing

Game Engine, Players & Web Plug-in, Virtual Reality, support for other engines

Moderators: jesterKing, stiv

kali
Posts: 0
Joined: Wed Apr 06, 2005 9:46 am

Multitexturing

Post by kali »

Does Blender support (or will support) mult-texturing in GemeEngine?
If yes, how to use it. If no - could anyone tell me why (it is architecture problem, or just simply not implemented feature). I have searched forums and couldn't find clear answer, just notes that it is in Tuhopuu 2... Is it true multitexturing or implementation of GLSL (that could be used for generating shadows - i don't known, i am not an expert). Why it is not (or maybe it is ?) implemented in Tuhopuu 3?

ideasman
Posts: 0
Joined: Tue Feb 25, 2003 2:37 pm

Post by ideasman »

Its not supported. I had a talk to Joe the creator of HEMesh and he will consider multitexturing, but we need developers to put this into the engine.
Id be happy just to see it in Blender personally but blenders engine could benifit from it too.

oin
Posts: 0
Joined: Fri Apr 02, 2004 6:34 pm

Post by oin »

It'd be also good for those wanting to use Blender with other game engines.Once is there, the othe rengine coders can think about making an script to export a multitextured (uv, I suppose) into game engines.
Besides, is good for blender, of course.

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri »

I thought blender already has multitexture.
How is what you are talking about different from what blender can already do?
Except for the GameEngine, I understand that lightmaps and normalmaps and bumpmaps are now not possible in GE because we can't assign multiple textures to a face,... o wait, that's what blender can't do currently. :)

ideasman
Posts: 0
Joined: Tue Feb 25, 2003 2:37 pm

Post by ideasman »

Well-
Blender only supports 1 set of UV mapping per face at the moment, and 1 image for that UV map.
Supporting up to 16 sets of images/UVMapping Coords would be ideal.
it would make modeling for game engines (not just blenders) much better.

Blender supports assigning 10 textures to 1 materal. but these are only rendered textures, and these can accsess UV coords, but since you cant have multiple UV coords then textures can only accsess the 1.

With a new mesh datastructure it woule be a good time to Support-

* Max 255 materials per Mesh.
* Max 16 sets of UV Coords and 16 images (Would be added like edge data- default would be all turned off so would not consume memory when not used.)

Pierre-Luc_Auclair
Posts: 0
Joined: Tue Nov 23, 2004 1:57 am
Location: Quebec City, Canada
Contact:

Post by Pierre-Luc_Auclair »

ideasman wrote:With a new mesh datastructure it woule be a good time to Support-

* Max 255 materials per Mesh.
* Max 16 sets of UV Coords and 16 images (Would be added like edge data- default would be all turned off so would not consume memory when not used.)
Would we need to completely rethink the mesh structure for that or just adding to what we already have could work ?

ideasman
Posts: 0
Joined: Tue Feb 25, 2003 2:37 pm

Post by ideasman »

Since HEMesh is a new mesh structure being developed (Currently without UV/TEX Face) I see it as a good oppatunity to raise the limits.
Its probably not vaible with current mesh structure, unless ppl are prepared for major loss of backward compatibility. (Which they are not)

Brandano
Posts: 0
Joined: Mon Apr 19, 2004 6:03 pm

Post by Brandano »

I can see how there would be a loss of backward compatibility with existing python scripts (you'd need to point to NMesh.NMVert.uvco[n] instead than to NMesh.NMVert.uvco and to NMesh.NMFace.uv[n] instead of NMesh.NMFace.uv), but how much would it really affect existing .blend files? It should be easy enough for Blender to read the old mesh format and convert it to the newer format. What would be harder to do is to is to save a .blend file from a newer version of Blender that could be opened on an older version

ideasman
Posts: 0
Joined: Tue Feb 25, 2003 2:37 pm

Post by ideasman »

Brandano wrote:I can see how there would be a loss of backward compatibility with existing python scripts (you'd need to point to NMesh.NMVert.uvco[n] instead than to NMesh.NMVert.uvco and to NMesh.NMFace.uv[n] instead of NMesh.NMFace.uv), but how much would it really affect existing .blend files? It should be easy enough for Blender to read the old mesh format and convert it to the newer format. What would be harder to do is to is to save a .blend file from a newer version of Blender that could be opened on an older version
The HE mesh datastructure is totaly new, it will probably never open in a release of Blender, that dosent support it.

Python will probably have some mesh.isHeMesh call. heMeshs will have to be handled seperately.

oin
Posts: 0
Joined: Fri Apr 02, 2004 6:34 pm

Post by oin »

Speaking about high res 3d stuff, is also useful. When you are uv mapping/texturing a head, for example, it comes really handy to be able to use a second or third uv texture channel to blend just over an UV seam. This way, you wouldn't have to sew/match uv coord to uv coord more than in a raw quick mode. You could do that blending, (feathered texture, loose opacity in borders, making with an identical texture as base) with that uv texture you'd put over in another uvchannel.

Is not something I am discovering, is a very old technique in 3d I discovered many years ago in a Max tut, when yet U didn't know how to properly uv map, and I was more dedicated to hi res.

Of course, you can do it in plenty other ways, but is a very powerful feature.

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri »

ideasman wrote:Since HEMesh is a new mesh structure being developed (Currently without UV/TEX Face) I see it as a good oppatunity to raise the limits.
Its probably not vaible with current mesh structure, unless ppl are prepared for major loss of backward compatibility. (Which they are not)
Why is that? Loss of backward compatibility I mean?
Can't a single texture be easy translated into multi texture?
The forward compatibility I can understand (blender 2.25 will not load 2.40 files) but backward?

z3r0_d
Posts: 289
Joined: Wed Oct 16, 2002 2:38 am
Contact:

Post by z3r0_d »

joeri wrote:
ideasman wrote:Since HEMesh is a new mesh structure being developed (Currently without UV/TEX Face) I see it as a good oppatunity to raise the limits.
Its probably not vaible with current mesh structure, unless ppl are prepared for major loss of backward compatibility. (Which they are not)
Why is that? Loss of backward compatibility I mean?
Can't a single texture be easy translated into multi texture?
The forward compatibility I can understand (blender 2.25 will not load 2.40 files) but backward?
the MESH FORMAT is completely different

it is kind of like asking older versions of blender to support svg, I mean, it's just an image format right?

[that said, it ought to be possible to convert to/from HEMesh, I doubt blender will do it on load/save]

ideasman
Posts: 0
Joined: Tue Feb 25, 2003 2:37 pm

Post by ideasman »

You can alredy convert between HEMesh and normal mesh, its just then blender (on open) will not understand trhe datasctructure if its an older version,

Pierre-Luc_Auclair
Posts: 0
Joined: Tue Nov 23, 2004 1:57 am
Location: Quebec City, Canada
Contact:

Post by Pierre-Luc_Auclair »

ideasman wrote:unless ppl are prepared for major loss of backward compatibility. (Which they are not)
I'd be more that open to this kind of backwards compatibility. This is a needed feature, just like normals editing and hard edges. Nobody will even think to adopt it in the game industry it has all that.. I personally would like to, but I constantly find myself juggling between max and blender due to lack of these features.

BTW, the backwards compatibility issue is really ridiculous in a free software. Backwards compatibility is useful with 600+$ programs that not everyone can update constantly due to many reasons. In blender it's not the case, everyone has access to the new releases for free, so it is a bit irrelevant.

HEMesh might put an end to this, but I just hate manifold meshes. I just can't stand this restrictive workflow. At some point, I just wish they would drop it and continue working on the normal mesh that I really don't want to fall behind like it happened in 3ds max with EditMesh and EditPoly (the comparison is not very good). If they like Wings that much why not just exporting their models to blender.. Anyway, not going to get into that, it's not the point of the topic.

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri »

ideasman wrote:You can alredy convert between HEMesh and normal mesh, its just then blender (on open) will not understand trhe datasctructure if its an older version,
But isn't this *forward* compatible?

Old versions of blender can't read new files.
But new blender can read new files and convert old file meshes.
So what's the problem?

Maybe I'm mixing up what is compatible, the file or the software?
Pierre-Luc_Auclair wrote: BTW, the backwards compatibility issue is really ridiculous in a free software.
How is that? Old versions are not easy to download. And new versions have bug fixes that you might need. With blender, bug fixes and new features (making new bugs) are mostly combined into 1 release. Always giving the dilema to update or not.
Now there is even a discussion on removing the game engine. If 2.40 files can't be read by 2.25 then the blender game makers can't bennefit from the new features. But if there is a convertor I don't see any issue. Convert the hemesh into mesh. Save the 2.40 file, and 2.25 will ignore the unknown data and load the mesh. Or is this incorrect?

Post Reply