Hi guys I hit a dead end this week on the project I wanted to do, and this got me thinking, and you know what happens when I start thinking, it start wild fires.

On a serious note, the main issue I encountered is that with limited texture space and the lack of primitive creation means, creation some thing like a large town isn't really possible unless you slice it into manageable pieces after which, user friendliness goes out the door.

So I hit on the idea, of painting a mesh within the engine and allow the engine to do all the heavy lifting, this can be achieved with relative ease using a colour ID map. A colour ID map, is basically an additional map used specifically when texturing a model, with a compatible program and allows which ever program to select a face(s) on any mesh based on the colour it was assigned in the colour ID map, this allows individual polygon face painting, regardless of the it being a single mesh, this can allow, the unusual large buildings or entities a reality, without having the issue of scaling back textures till they look like lego.

This means you can import a very large mesh, use a colour ID map, and assign textures to it with relative ease, however I am not sure how the engine will deal with the texture it needs to create.Doing so will allow even the painting of smaller objects even characters if it has a colour ID map.

So I need some help formulating the idea so that I can pitch it to lee and have it possibly added to the voting board, maybe you can think of some thing I have missed. ?

Sounds very similar to the way Lee is implementing EBE, i.e. a 16 colour map per instance. To get something like this working with generic entities wouldn't each face in the model need to have an 'ID' value associated with it?

Instead can't a bunch of entities share the same texture files, isn't GG already clever enough to only load shared textures once?

No, the idea is an entirely different beast.Take for example any building in the TGC libary, if it has a Colour ID map you can assign new textures to it quite easily as you sample a specific colour for example Red, this allows you to apply a texture only to the part that is RED of the UV map meaning it ignores every thing else in the UV map and only paints the red parts, meaning you can literally billions of possibilities.

Textures will have to be seamless for walls, roofs and floors, however you would need to be able to detect how large the surface area is of the face(s) you are painting.Unlike the EBE, you can use any MESH you want any size, or polygon count, it means you can re-texture a weapon or character, building entity you like. However the more I think about the idea the less I think lee would be up for some thing like this as it is quite complex to say the least.

But the benefits are massive in that you wouldn't be restricted like you would be with an atlas texture, and you wouldn't have to resort to import building by building and allow a far larger scale import. So it has nothing to with EBE and the way it works, the intention is to use a texture system similar to that of a BSP system, but instead of creating meshes within the editor, you create your entire level or city or parts of a level in a 3D editor, assign a UV, render the colour ID map, Have a folder with pre-selected texture, load the mesh much like the model importer and assign from a selection of individual textures to it, and some how create texture atlases or multi texture approach or whatever method is the most performance friendly.

The approach is much much different to that of EBE in that you already have a prebuild mesh and assigning individual textures.EBE is limited to that of 16 texture atlas meaning you can't swap atlases around, and you have to build what ever you want and that is limited to certain shapes.The benefit is that using a prebuild meshe(s) your draw calls will be less, while the memory footprint might be larger, there is zero mesh restriction and you can have more then 16 different colour ID's on your map and building texture output would be unique every time.

The only alternative is what lee has been talking about the past 3 years is doing a composite entity where the artist can weld several different meshes together to form one larger entity, but that has limitations of it's own, and there has been absolutely no word on that, or even on the voting board, so expectation is 2025 for that to ever see the light.Putting some thing together to pitch for the voting board has a better chance then the fabled composite entity lee has promised.

The engine has serve restriction on meshes and this is a way I can see to circumvent issues with limit texture space and the lack of primitive creation.

This is what a colour ID map would look like.


After being textured based on colour ID

I think this is an awesome idea. This is similar to the way textures work in Fuse. I REALLY like this idea!

I could actually see this sitting in with the EBE texture layout with 16 texture Atlas using colour code as you suggest for each area of the existing map. If these colour coded areas matched up with the EBE texture layout it would mean selecting Atlas maps by name. You might run into some issues with small details all the same and easier to simply retexture using existing model uv's in a paint app than painting complex models such as characters or weapons,.would work well for architecture and such though. I think overlay decal brushes for foliage and grime would appeal more.
The only way I could see this working in GG however would be ability to vertex (face) paint models using brush, other than that it would require that you do it in modeling app and bake the colour map, which kind of defeats the purpose of an easy game creator editor addition. Even if it could be done in editor you might want to blend some textures etc which would require some kind of control over the degree of blending or overlay. Which brings to mind overlay brushes for scratches/dirt etc.
Not bashing the idea at all and anything which allows users to customise their levels making them more unique and less generic would be really welcome, I suspect all the same that it might be against Lee's ethos as he is unwilling to go down any road which turns GG into anything resembling a model application.

ZBrush has a great feature which can use a selected texture which can be overlayed and brush painted directly onto the model then baked out to texture in seconds using the existing uv's with no colour maps involved.
There are a lot of advantages to the idea for users but the implementation of it into GG is beyond my thinking. It may be too experimental at this point and something for further down the road...nice though

@rolfy

If the store and TGC which are so dead set against multitexture approach, support it offically It would solve my problems immediately.While the engine does support multi textures.Lee simply considers it too much of a performance hit to officially support it in gameguru and the store.

Honestly there needs to some head way in this area of gameguru, it's is seriously lacking.Draw calls VS memory footprint I would choose the memory footprint and day of the week.EBE doesn't solve it in any way, as the shapes are too limiting.

Lee has spoken about the composite entities for eons and like I said it isn't even on the voting board, unless some one starts advocating for features completely on the other side of the spectrum, gameguru is going to be boring for years to come.

I forgot we don't even have the ability to change textures from the properties menu unlike Classic which granted that ability, frustration aside, meshes, textures, and level assembly, has always been the most neglected part in most of TGC's products.

Here is some more information for everyone to discuss, about the actual implementation.

From WOI: "Well if you use the existing model importer, there is far less to do,
it would mean showing a prompt at model import asking if this model
has a colourID map.This is where the model editor then applies the
colour ID map directly to the model.
After which it would load a separate menu with a texture menu, This
requires a default texture library folder in gameguru.

Drag and drop approach should work well. Not sure if possible but
perhaps having the ability to scale or tile textures might be handy,
it doesn't entirely fit correctly.

Prebaking shadows should be nice, but there should also be an option
to turn it off if you're going to use realtime lightmapping, save and
load, not really needed, but undo most certainly

As to time, I am not sure how this can be implemented, but using the
existing model editor should save some time, a 1 week at most,
realistically with every thing in between 2 weeks ?"

Feedback welcome!

Thanks Lee for taking the time to reply.However, how can the limited texture space be addressed, that was the biggest issue I encountered, is it possible to load the textures in raw chunks instead of conventional texture method, that is the biggest issue it needs to address so to allow 16 or 18 textures for example.