• We would like to reuse some parts. In this case the engine (A). Is it possible to make a separate model for the engine use it with other buildings too? Same for the Flag (F).
• How do I model the Rope (B), because it will be stretched out if the cage gets deeper and deeper? Maybe solve this entirely via script, like in CR?
• Is it possible to define some "Top Face" Parts like in CR? In this case the clonk should walk behind the Beam (C).
• How the cage is handeled? Separate model? Same for the turning wheel, how it will be turned? Should I make some bones?
• Where do I comitt the model, when they're ready? It's really important that the model works in the first place – later the uv-mapping and textures will follow!
• The 'Windows' (D) will be solved via Alpha-Maps, not via geometry as currently shown.
• The engine itself will look more detailed, it's just a sketch.
• The lorry (E) need to be a little bit smaller to fit in the current cage.
• The Flag will be a separate object, with of course less polygons as shown. Overall polycount is ~1600 Triangles.
Concerning the rope: It could be done the way it is done for the current elevator (which I don't know.) I'd have some ideas how to approach this otherwise.
Models go into the resources repository. http://git.openclonk.org/openclonk-resources.git
> It's really important that the model works in the first place – later the uv-mapping and textures will follow!
Right! But also, before thinking about "seperating models", "bones" or "how does the rope work", I'd acutally like to see the real concepting phase through, first. That should include some color and texture paintovers, picking out a rotation to show the object ingame, putting it next to a colored wind generator prototype, trying out if that engine acutally fits on all the other buildings, stuff like that. sortof-kindof "Lets do /all/ the concept art first" before moving to the next stage. that way, changes in style and color won't affect models, uvs and textures as well, but only the concept art itself.
I also think it is a good idea to do the core building set in one. so we can tweak and modify all buildings and shared parts together. It would be nice though if we could also see the buildings in game at all times as this is what counts.
Maybe we don't need real game objects for the reusable parts. We can model them and reuse them internally as 3d objects.
Concerning the flag we need to see if we want any indication to who a building belongs...
>We can model them and reuse them internally as 3d objects.
But still they share there uvmap with the 'parent'-building, which is extra effort every time one building does include a shared-part.
So That other object and Map developers can easy use them. for Dekoration of their Objekts and let the Game keeping an Unified Look.
Also if the elevator is destroyed, you can just change the Model of the Engine to a shreddered Engine wich falls out and Burns seperatly.
And so You Dodge the Problem with an extra Texture or Shared UV Maps and Keep the Other Texture channels for mipmapping and all Those Stuff there may Come.
Just my 2 Cents
Still it should be possible to build all three versions: straight, left and right.
We just decided to have a general take on the graphics of the game.
As this is the internal forum for the graphics people, here is also not the place to discuss if we should or should not do some model or another one.
i wonder if combination of 2 elevators will be still possible then?^^
>i wonder if combination of 2 elevators will be still possible then?^^
I have that same question. :)
and then go to where you about to place another elevator (with hammer and stuff) and let it turn to left, and then place it next to the first elevator.
(the placement preview will "magnetize" to the other)
then those two elevators will be combined (the mesh stay same for each one).
so you will get a bigger elevator for transporting bigger vehicles (maybe an airplane).
its a pretty nice feature^^
If you move a flipped elevator near enough to another one, you'll get this preview with the CONNECTION icon inbetween. When built, the elevators will work as one:
With two elevators, you can transport catapults and blimps! Also, the flipping works with every building. But only the elevator makes use of it. With other buildings you can only decide which side the objects will get thrown out (e.g. with the foundry or the sawmill).
> How do I model the Rope (B), because it will be stretched out if the cage gets deeper and deeper? Maybe solve this entirely via script, like in CR?
This is done like in CR via FacetTargetStretch=1 in the ActMap (of the rope object), so don't bother with that. Downside is, you can't have a texture but that's a feature of minor priority, I'd say.
> Is it possible to define some "Top Face" Parts like in CR? In this case the clonk should walk behind the Beam (C).
That's done in a not-so-nice way but currently the only way possible:
You have two models, one front part and one back part (cut in half by screen layer, z?). These two get assigned to two different objects, one back and one front (local Plane = higher than clonks;), the two objects are attached the mother object. An example is the current elevator case or the blimp.
This is far from perfect but - as I said - currently the only way to have a top face in a model.
> How the cage is handeled? Separate model? Same for the turning wheel, how it will be turned? Should I make some bones?
The cage is a seperate model, yes. Just like with the current elevator. And for the cage's top face, you'll need to split up the model again, sorry.
The wheel is turned via simple animation. Matthias should be able to help with that. You don't necessarily need bones (but you can use them if you think that's better / easier).
> Where do I comitt the model, when they're ready? It's really important that the model works in the first place – later the uv-mapping and textures will follow!
The resource repository or - in case you don't want to hassle with git - post it here with the request to someone to upload it into the repository. Self-uploading is encouraged, of course!
All in all I think this is a great model! It shouldn't get abandoned for the sake of the 'cliff hanger' model from above. It guess the two models can coexist. Maybe we can even figure something out to make the other one a little weaker (weight-lifting wise) for the advantage of cliff use. Also, this one is far more compact, that's an advantage in itself!
>Is it possible to make a separate model for the engine use it with other buildings too?
Yes, parts that are shared or might be shared amongst several models should exist as separate models in the resources repository. Otherwise it will be unnecessarily complicated to include them in other models (the separate model would have its own square texture, otherwise it were scattered all over the uv map of its parent model). Perhaps it is even possible somehow to include models from other files in one blender scene so the reused parts are not copied & pasted all over the resources repository?
The exported ogre model however should be just one object. IIRC it is possible to link several different .material files and thus different texture files (for the different separate parts) but I'm not 100% sure.At least CK could answer that.
What is the best way to go here depends on the technical implementation: can one OCD have several .mesh, several textures, several .material?
SetMeshMaterial(). One can also have more than one Graphics*.mesh file, and then switch between them using SetGraphics. However, each .mesh file defines a mesh with all its submeshes -- individual submeshes cannot be loaded from separate files.
M: Here is the final candidate for the model. please let me know if this is all right before I go on to the texturing stage.
C: It's all grey. I'd need to see it in color.
M: Okay, here is the model with some simple base colors filled in. please note that there is no real texture yet. The material will look more refined and realistic once I start working on this step. This is just to confirm the design of the model.
C: I've shown it to my higher ups. They said the color is to flat and it looks like a plastic toy, like playmobile. They did not like that.
M: Okay, here is the model with some simple base colors and some simple procedural noise filled in to hint at a possible structure. please note that there is still no real texture yet. The material will look more refined and realistic once I start really working on this step. This is just to confirm the idea, the shape and design of the model.
C: I like this one more. Just give that other part of the model the same structure and it's done.
>This gives the model a very organic look, almost as if it has been grown rather than built.
All of the beams almost collide with each other, which doesnt make any sense to me. It looks far to massive to make any sense. And yes, I like sense :-)
The guideline for previous buildings was to make them have a look as if they had been hammered together (a bit) which means that beams don't have to be perfectly orthogonal/parallel to each other, roofs may be a little bit inclined etc. The beams and planks themselves would be straight though because they had been shoved through a sawmill.
To come to my personal opinion here: The idea of the style is o.k., though I am a bit fed up with this World of Warcraft cartoon look which this somewhat resembles in my opinion. I rather like the previous "invention" style and Fungiform's "blueprint" style. Also, to go with a completely different style now is in my opinion infeasible thinking about all the work that had to be redone to get to a consistent look.
The idea of the structure is cool. We get the gameplay advantage of a crane-like elevator plus it doesn't look like a banana but even - yeah - like a crane! I'd like something like this but in a style that fits to the rest of the buildings, and perhaps without this odd lush double-roof.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill