Quick Question

[Prototype]

Models made for the Flan's Mod thing aren't necessarily models for FC. Making fighters fly and turrets shoot should be a higher priority than modelling them. We're putting the cart before the horse here.

Yes, but while not everyone can do the making them work, more people should be able to make these models while we wait for the engine work to be dome,if we already have these models ready, it saves a lot of time, when it comes to putting them in the mod.

[Vinyl]

Did I ever mention I can use Blender well?

[Prototype]

Did I ever mention I can use Blender well?

I don't know how good blender is for exporting as a format you can put into the game, but as of the present I don't think it's possible, however seeing as the model system for futurecraft doesn't exist yet, blender could have the potential to be a good model maker, but currently it's not so good at making models you can actually use (without an expert understanding of minecraft and the java language, which only fr0st has been proven to have)

[fr0stbyte124]

IIRC, there are going to be lots of models of wings, *, engines, nose cones, and such that can be matched together as the user likes to create varied fighters. Something similar will go for tanks and turrets.

That might look odd. The fighters will still look uniform (They should all connect together so they have similar shapes) and the different textures and unsmooth connections might make it look ugly.

Fighters, turrets and such will have a priority because they are basically the whole equipment you get. (The turrets are especially important)

I would not recommend custom models for fighters and such, stitching them together will be too difficult, it just won't happen, we will already have enough variation in the ships themselves. I say just go with a selection of standard models, perhaps two or three of each role for each type of model (e.g. For turrets, two types of AA two types of howitzer ect.)

That is still a lot of models we need. So far we have one, and it's been made by a standard forum member, rather than a dev.

If the sockets are standardized, you'll be able swap out any pieces of the model you like. No extra processing.
I think this, at least, is very much worth doing. Nobody has anything like it (in minecraft. Borderlands makes fantastic use of it.)

[Iv121]

Yea but again the standard sockets mean that they all have a similar form.

[fr0stbyte124]

Yea but again the standard sockets mean that they all have a similar form.

To an extent. But then every car and truck and plane in the world have similar forms to every other car and truck and plane.

[Iv121]

Which is actually true. The point is that those differences are accepted and feel natural for us, but when you go sci-fi people expect design to vary even though in real life all space ships will indeed look the same.

[fr0stbyte124]

Well then we don't make it universal. Different vehicle classes and categories have different sockets which are incompatible with those from other classes. I'd avoid doing it too much, because this is already going to be horribly complicated as is, but we can do it a little.

At some point we need to start consolidating or this mod is going to become unmanageable. But I think there is plenty of room for flexibility before we reach that point.

[Prototype]

Well then we don't make it universal. Different vehicle classes and categories have different sockets which are incompatible with those from other classes. I'd avoid doing it too much, because this is already going to be horribly complicated as is, but we can do it a little.

At some point we need to start consolidating or this mod is going to become unmanageable. But I think there is plenty of room for flexibility before we reach that point.

I agree, let's just go with a set of standard models first, then maybe cut then up later.
Although really models should have a lower priorit than ships, it's something we can do towards the end of the mod.

[fr0stbyte124]

Seeing as how models are going to be the domain of the 3D artist and are mostly unrelated to how ships work, I don't see any reason we can't do them both at the same time. From my end, it's as simple as drawing a different range of vertices to the screen. So long as the models have standardized fittings, that's seriously all there is to it.

[Prototype]

Seeing as how models are going to be the domain of the 3D artist and are mostly unrelated to how ships work, I don't see any reason we can't do them both at the same time. From my end, it's as simple as drawing a different range of vertices to the screen. So long as the models have standardized *, that's seriously all there is to it.

I know I have probably said t quite poorly, but what I've been saying is make the models now, so that when we get puns to having a way to implement them, it can be done quickly, but the making of the System that imports them will be developed after the primary important stuff.

As for standardising them, what format would be best to save them in, for at the moment I am building models through the java file for flans mod, however the actual code that make for the 3D or 2D shapes could be isolated and extracted, but files just made in techne can just be exported as java, but I imagine that we are going to have to use something like turbomodelthingy, otherwise we will only be able to use boxes.

I'm getting too far ahead here, main point is that we can make models now, but they need to be in a standard format for later, so should that standard format be the java export from techne or something else.

[fr0stbyte124]

First of all, whomever is responsible for all these word replacements is going to get stabbed by an aye-aye. If you've ever been stabbed by an aye-aye you will understand how awkward that is for all involved parties, but I'll do it if I have to.

Second, Mackeroth has requested moving model importing up the priority queue for the benefit of the other team members, and I think that's a good idea.
Unless someone has something better, the standard format will be wavefront .obj files. I'm not sure what that will mean for animation, not being familiar with 3D modelers myself. That part may still have to be done by hand, but this shouldn't affect the static model terribly. I'll look into it. The important thing here, though, is that there is no reason we need to be generating primitive shapes one at a time from lines of java code. We may have to make some pretty elaborate stuff down the road, and I would rather us not be restricted to whatever Techne or Turbomodelthingy can support when that time comes.

*edit*
Actually, it looks like Turbomodelthingy already has some .obj support. If it is doing what I think, then you should be able to use it as-is to import .obj models into Minecraft, including things which aren't one of its built-in shapes. Does anyone know if this is the case?

[Prototype]

I have not yet worked with .obj files, if I have, I wasn't aware of it. However I can take a look at these files, I can probably find some way of importing them or at least a way of extracting the polygon information and other information, where we can play around wih it.

[fr0stbyte124]

Alright, I looked into turbomodelthingy a bit.
Let me know if any of this is incorrect:

TMT is a Java library for Minecraft which adds extra modeling functionality for modders. This includes an interface for making cubes, trapezoids, and cylinders which can be generated in-code (Minecraft style). It also includes functionality for importing raw .obj files and even skeleton animations, though I don't know what format those take. It compiles stuff to display lists, which I am not crazy about, but the whole thing looks perfectly serviceable. It does not, however, have a graphical designer, so you'd still be restricted to using techne or a real 3D modeling program. Still, that is basically all the functionality I would have have had to write myself, so if it's up-to-date, I see no reason not to use it for model loading.

*Edit*
Okay, it doesn't import skeletons or animations. If you want to use them, you create a bunch of static pieces of the model and attach each to different bones, which you set up in the code. The bone framework just manages the nested matrix transformations for each piece of the model. So even with TMT, you still have to do animations by hand.

[Chairman_Tiel]

tys