Transport Tycoon Forums

I love where TTD is going. I've seen some amazing graphics for the (proposed) new engine and I would love to get involved. Alltaken has already taken the initiative but what I would like to see is more actual ".blend" files, or Blender compatable files, posted in this forum. People have always shared GRF's and I think for the most part they're always given credit for their work even if it's used/modified by others.
Sharing files means we can learn off each other and end up with a better end product(OpenTTD). I've only just started with Blender(thanks Alltaken) but I would love to become part of the graphics team.

A few questions though:

a) will there be any need for NFO(or equivalent) under a 3D engine, and if so how I can I help?
b) what format are the new GRF files likely to take?
c) being fairly fluent in HTML, JSP, ASP, JavaScript and Java can I be of any use to OpenTTD?

Anyway, hope to see some ".blend" files here soon, thank you all in advance.

Raven has created all the vehicles we would need for a playable game (with way to many options of vehicles LOL)

the thing is i am still talking to him about what license type thing he wants to use, and have not finished that conversation. nor have i gotten any of his .Blend files.

the goal is to finalise a few more things before posting the .Blend files, because i do not want to circulate unfinished .Blend files. they become an Administration nightmare, i don't want to see people thinking unfinished files are finished, and distributing them, then using those to render sprites.... it becomes ultra messy very quickly and is not easy to fix.

so first before anything is released publicly (as in source files) they will need to have a set of standardised Light setups, and i will need to work out a method for creating a "company colour" overlay for vehicles.

a lot of this stuff is more admin work than art work. (unfortunatly i have been doing basicly only admin work.)

Raven is currently going to release some renders of his finished models and we will compile a list of what has been done and what needs to be done. (talked to him the other day)

i am at university right now so can't put in big time efforts to the project untill later. but things are happening slowly, and since their is no GFX engine yet for them to go into its not a big deal. (they will get put in some time though )



firstly its NOT A 3D ENGINE. it will be a 2D engine that utilises 3d software to create sprites. to the player it will look 2.5D, it will be obviously 2D but kinda like Sim City looks 2D

and yes it will need an NFO type file, but this will be a lot more advanced i would suggest, since the GFX will number many more, and will be able to have many more functions.



Compressed archive, containing 1-or more folders containing the required sprites. and in the top level a data file like the NFO type thing.

example

/Bigfastbus.OTG
-data.dat
/main sprites/
--sprite 1 through 72.png
/company colour overlay/
--sprite 1 through 72.png
/fedex custom colour/
--sprite 1 through 72.png
/smoke/
--1-6.png

the graphic file can contain any GFX that are needed by that vehicle, and the data file will describe this (coders can work that stuff out)

many files would contain only 2 sub folders, and just use shared/ common smoke.



you could possibly help me on the coding of a Blender community site (i just need a small amount done.) you might enjoy it . if you are keen give me a buzz

Alltaken

_________________
http://doug.flipdesign.co.nz/gallery/

Alltaken, I think you're misunderstanding a few things:


Um... like the PlaneSet? The USSet? P:GS? OpenTTD?
Just about every single project on this forum is distributed that way.


If the way NFO was "designed"[0] is acceptable to you, then yes, we can.

[0] This is what we need *now*; we'll tack a new bag on the side when we need something new.

_________________
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser

what things



yeah i am not talking about "sets" i am talking about "individual files" i.e. a single train, a single bus, a single plane.

the missing things in the current files are "fundimental". having united standards in things like light angles, light intesities, rendering settings, material settings... will provide a game that will look like its meant to be together. if we release things and people start doing work based on them, they will need to re-work lost of their stuff.

i am wanting to quality control the files and set them up perfectly before releasing them (individual vehicles this is)
but before that i need to standardise things so that artists are not trying to fill in the gaps of things that are missing "and getting it worng"

and OTTD doesn't come out with half working extensions? (except the new AI ) it becomes messy if it does.





Ugggg, this thread is about New GFX, so is 100% refering to what is new, and not talking about the current graphics (if i understand correctly)

and i would be raterh disapointed if NFO was used at all in the New GFX engine. somthing similar would be created to "replace" it. since we wouldn't be using any of the old GFX anyway, there would be no conflict, or reaosn to keep the NFO system.

a new system would be far more efficient, and more taylored to the goals.

unless of course you want a patchwork of dirt cobbled together with some sellotape and a soggy mushroom to create a game. why keep NFO if there is NO reson to do so in the advent of new GFX? it makes no sense to me. and i couldn't understand it from either a coders OR a graphics artists point of view.



"Or equivalent" is the key idea with this one.

Alltaken

_________________
http://doug.flipdesign.co.nz/gallery/

The advantages of NFO are: (1) it's already designed, and (B) it provides enough power to do pretty much anything.
Its disadvangage is that it's nearly incomprehensible, sometimes even to the author.

I've probably missed all the relevent posts, but in order to produce a coherent design, we have to start with a full list of design specs. Here are some of the things that should, IMO, be considered before writing a format that duplicates the power of NFO.

• Sprites per vehicle
• Control over which sprite-set is selected:
  
  • How many random bits do you need?
  • What variables do you need?
  • Do you need variable-variable comparisons?
  • What operators (arithmetic, boolean, comparative) do you need?
• Full stats list
• Assumptions

_________________
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser

i have pretty much come up with a list of requirements from a graphics designer POV (not a coder POV) as to what it needs.

it has been posted in the development thread saying "new Grpahics format" or somthing like that.

i don't think NFO can handle it. i think since a new GFX engine will be created anyway, you may as well make the graphics format data file new also (it would require probably less work than editing the NFO files)

sprites are being handled way differently than they are currently, there will be no .GRF files. all sprites will be stored as seperate images, and loaded as needed, meaning sprite sets can be added to without touching the existing stuff.....

BTW one thing that is a 100% must have for an NFO replacement, is copyright, who created the sprites and a bit of info about them if they want.

BTW, the new system can use some principals from NFO, it doesn't need to be a reinventing of the wheel, but it does need to be a major new product. (like the difference between a steam engine and a modern electric.)

also it should be largly human readable/ editable, so artists can do the work, without the coders needing to do the work (which makes efficiency sense)

BTW i am not even interested in getting into this whole argument. i know i am right, and am not changing my views or opinions on what features it needs to have. the form that the final takes i don't care. as long as it fits ALL of the specifications required for the format. currently the NFO files fullfill almost none of them (a few but not heaps)

Alltaken

_________________
http://doug.flipdesign.co.nz/gallery/

Again, I'm NOT suggesting that NFO, in its current format, be used; something more readable would be far better. It's just that if your format description reads: "Start with these parts of NFO, then add thus-and-so," it'll probably be better than just "Do this." You'll be starting with a proven format. As a result, the new format will be produced more quickly, with more people who understand at least the basics.


When re-reading the New Graphics Format thread, I found this postwhich contains nothing that can't be done with the NFO format. If that isn't the correct post, can you point me to the appropriate post? Failing that, enlighten me. What does the new format require that NFO doesn't have?[0]

Don't say "Sprites in separate files". That's a function of GRFCodec, not the NFO format.
Similarly, the 72-sprite/vehicle thing is hitting TTDPatch limit, not a NFO limit.

In general, please make sure you aren't confusing "NFO" with "GRF" or "TTDPatch".

[0] If this sounds slightly sarcastic, it's probably because it is. I'm failing to understand how you can need much more power than the NFO format provides. Obviously, NFO has its failings, but, IMO, most of that is in the readability department, not the ability-to-do-stuff department.


Already in NFO. Arbitrary text, including copyright &c. can be placed in the action 8.

_________________
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser

well it sounds like NFO can do it then....

GRF codec, is where the GRF file is encoded with information about the sprite locations within the image?

basicly a file is needed to define the sprites in terms of their filenames (so the game knows where to look). and this file would most likely say what these sprites do so that the game knows how to use them.

the copyright part needs to be readable by the game, so that in the about box of any item, there is a notice of who made it and how to contact them... not so that you can just load the data file and read it. it needs to be a part of the designing of a new GFX engine from the start.

agian i don't care how its done as long as it works and does what is needed.

the NFO right now, just seems so cumbersome.
i don't say we don't use info thats in it. (since most of it is required) i just say it doesn't need to be in that format.

Alltaken

_________________
http://doug.flipdesign.co.nz/gallery/

I can appreciate that you dont want unfinished blend files being passed around, but is there any chance you could post one or two vehicles just so I can get some sense of scale and detail. I've only just started using Blender and having a few existing vehicles would make learning a lot easier. I've downloaded camera.blend but I would like some existing models to help get me started.

ok sure, this file is for "research purposes only.

the detail of this file is far supperior to anything you need to do. (it was not custom made for the game)

using squarish shapes rather than subdivision surfaces for the vehicle will be fine.

if you render out an animation of the file you will get all the sprites for that vehicle.

Alltaken

_________________
http://doug.flipdesign.co.nz/gallery/

Thanks AllTaken. I've since found a few sites containing .blend files (including yours I think!)
I've been pretty busy learning Blender and trying to get my ISP to let me get my own website online but if you still want help with your site then maybe contact me via a private message or at my email address

Hi guys,
I'm new here and I made a lighthouse.
I used the blend-file provided in the sticky as a base, but it's probably outdated or something because the lighting doesn't seem to match the lighting in pictures I've seen going around here.

Can't figure out how to add multiple attachments so here's the blend.

EDIT: oops .blend files are not allowed

I like it very much, it's a really nice work.
I just think roof and lighthouse needs more texturing (brick)

Also, the shadow is casted somewhere to the north.
I think it should go north-west

IMO shadow should be blured, or just removed... for all sprites - to avoid simple yet unexpected and difficult to fix nasty bugs

Hope to see more from you (houses, offices maybye?)

WOW this is fantastic.

keep them coming.

the more things which are made, the more i will be able to determine if the lighting setup needs to be changed, based on some of the things people are creating, i think i will need to create a new lighting setup. i have just purchased the book, "digital lighting and rendering" which is all about lighting, so i will be able to apply those skills to a new and better setup.

we can work out the converting of lights between files at a later date, it should not be a problem. untill then though, this image is fantastic. i really do love it.

Alltaken

_________________
http://doug.flipdesign.co.nz/gallery/

/me runs out of the house to get some tissues since he drooled all over the floor

awesome

_________________
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."

I tried making my own lighting setup, it's realy basic (1 hemi, 1 casting sun, 2 non casting suns) but it seems to look ok.

EDIT: blend in zip

Very awesome job! This one looks better IMO

definatly a better lighting setup...

looks like you are pretty much using a 3 point lighting setup from the image (havn't looked at the file yet, i will in the weekend)

nice work

Alltaken

_________________
http://doug.flipdesign.co.nz/gallery/

(speechless)

This just ROCKS !

_________________
If ain't broken, don't fix it. | JabberID: stavrosg@jabber.org

Hello, I am a signature virus. Please copy me to your signature to help me spread.