Objects for Grafics Replacement

[Aracirion]

Hi there

I used to play around with Lightwave some years ago, and now that I saw this cool project i thought maybe some of my objects will be of some use to someone, finally, and I might even do some new ones if I get the time.

I just don't know Blender, so Alltaken suggested I just post my models here and someone else can do the texturing/rendering.

For conversion, I tried saving as lwo and importing into Blender and it seemed to work, please tell me if not.

[Aracirion]

this is a first Building i made. The shrubs have several layers, I colored them green and added procedural transparency to give it the a more voluminous look.
Please tell me whether you can import the lwo file.

[Red.xiii]

any chance of a .dxf file? I know they import correctly...

[Aracirion]

I added new version of dxf/lwo/obj file. for me lwo imports best into blender. Can other people not import it?

[Aracirion]

hey guys, can anyone convert my model so its usable in ttd? Sometimes I feel like making some more but if it won't be possible to use them there's no point!

[bobingabout]

converting the graphics is 1 thing, making it work is something else, you need to know NFO to do that...

[Aracirion]

NFO? I thought once someone can open the model correctly in blender its also possible to texture it and use it for ttd...?

[bobingabout]

once the graphic is rendered properly, you still have to tell the game what to do with it.

[Aracirion]

Well I wouldn'do that anyway, I was talking about making objects for Enhanced GFX replacement, but as I use lightwave and not blender I could only make the models but couldn't texture and render them myself, so someone else would have to do that. But it's not helping anyone if I make objects and afterwards nobody can use them.

[Korenn]

once the graphic is rendered properly, you still have to tell the game what to do with it.

what are you talking about?
this building is obviously for the new 32bpp version, and that is nowhere near file formats yet.
(And even then, it won't have anything to do with nfo and grf encoding)

Aracirion: as far as I got it, .OBJ will load fine in blender.

[DaleStan]

(And even then, it won't have anything to do with nfo)

It seems to me like there are really two options here:

1. Write a program that takes your "plain text" spec file and converts it to NFO, then use the already-(mostly-)working NFO support in OTTD and be done. [1]
2. Write a program that takes your "plain text" spec file and converts it to some other, yet-to-be-specified easily computer-readable format. Then start from scratch implementing this format (which for NFO took many, many months and won't be significantly faster no matter how nicely you design your new one), fixing bugs, redoing the specs because you find things you need to do that can't be done, restart coding yet again, fixing the limitations of specs. Deal with the headaches of supporting two incompatible formats internally (unless you want to drop support for all existing graphics). Repeat as necessary.

My point is, why not use a format that works, can do just about everything that needs to be done[2], that there are many people out there who know how it works, and that OTTD mostly supports already? Why bother making all the mistakes that TTDPatch made all over again in a new design?

I'm not saying NFO is perfect. It has warts, and some things aren't designed as cleverly or cleanly as they could've been (because it's a grown design that grew as artist's demands increased). However, it is very simple for doing simple things (you can make a new train with four or five lines of very simple "code". It can get very complex too, but only when complex things need to be done. You cannot remove the complexity without losing its power and sophistication. Any new design will need to be just as complex if it needs to be able to do what NFO can do[3].

If the hex-ness of NFO is the only thing that bothers you, then it's the only thing that needs fixing. This means either improving/fixing GRFMaker, or writing a "plain text"->NFO converter. A variation of the latter would need to be written even if you come up with your own format.

So why not NFO?

[1] Whether the graphics are 8bpp or 32bpp or 256bpp does not matter here. The way sprites are encoded in the file is irrelevant. NFO can work just as well no matter what type of sprites you have. [It doesn't even matter if you have 3D meshes and no sprites at all; that'll work too -- DaleStan]
[2] And can relatively easily be extended to support new things.
[3] For example Locomotion has a very simple format. As a result it can only do simple things. No repainting of wagons after N years to show a new historical livery. No showing of dirt as vehicles get older. No random variations in colours. No seasonal cargo acceptance/production of industries. No sophisticated animation control. No sophisticated station designs. No simple support for trainsets, other than defining a new vehicle ID for each loco and each wagon in each train set. Etc...

And the rest of that thread

NFO doesn't even have to be encoded into a GRF; if there's a different container that, for whatever reason, works better, then go for it. You will still have to support GRF and $OTHER_FORMAT, but GRF is a static format, so trying to support two containers would be less of a headache than trying to support two programming languages.

[Korenn]

stop going off-topic please. if you want to discuss file formats, please do it in the appropriate thread.