Board index FlightGear Development Aircraft Liveries

Beechcraft b1900d template

Discussion of aircraft textures and liveries

Re: Beechcraft b1900d template

Postby hvengel » Wed Aug 13, 2014 10:49 pm

Perhaps you could create a detailed howto for this work flow to the FG wiki. I think it would be very helpful to others.
hvengel
Retired
 
Posts: 1127
Joined: Sun Dec 24, 2006 5:35 am
Location: Minden Nevada

Re: Beechcraft b1900d template

Postby Johan G » Thu Aug 14, 2014 7:04 pm

hvengel wrote in Wed Aug 13, 2014 10:49 pm:Perhaps you could create a detailed howto for this work flow to the FG wiki.

Either as an improvement to Howto:Edit a livery or as a new article, say for example Howto:Creating a livery paintkit. :wink:

Maybe there could also be some descriptions of what unwrapping is and how such tools could be used, but in a unspecific way so that the reader get idea of what to look for in his particular software.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6634
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Beechcraft b1900d template

Postby hvengel » Sat Aug 16, 2014 12:00 am

Actually I was thinking about a detailed workflow type document that was intended for aircraft devs. The "Howto:Edit a livery" article is very general and is light on details and does not lay out a specific workflow or define what tools to use for what functions or talk at all about specific best practices. It is clearly aimed at end users and not aircraft devs. It has nothing on effects which are apparently being used by the b1900 (at least a reflection map and a light map - does it use a normal map? - does it use a reflection map for anything beyond the spinners?). There are lots of details involved in setting things up to use the effects system and all of this is derived from the same UV map used to create the paint kit. So effects and the paint kit are tied together and created as part of the same development process/workflow. This is what I would like to see documented.

I also agree that tools for the UV unwraping and packing are something that I want to know more about. Are you using the tools in Blender or are you using some type of add on or an external tool? Could you provide details on what tools you are using and what your UV workflow looks like.

I think we have enough things out there that are "unspecific". I want to see something that is VERY specific and is extremely detailed and that has every little step documented. A recipe than can be followed to create a good UV map and then create a paint kit, effects textures and so on.
hvengel
Retired
 
Posts: 1127
Joined: Sun Dec 24, 2006 5:35 am
Location: Minden Nevada

Re: Beechcraft b1900d template

Postby Johan G » Sat Aug 16, 2014 3:11 am

High detail would require more maintenance in the future (but I might just as well be a bit damaged by a "Wikipedia is not a manual" mindset from my edits over there ;) ).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6634
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Beechcraft b1900d template

Postby hvengel » Mon Aug 18, 2014 5:39 pm

No matter where documentation ends up it needs to be maintained so maintenance of documentation is NOT a wiki issue. I do agree that the wiki has lots of stuff that is of limited usefulness because it is either very outdated and un-maintained (the bump map and reflection effects wiki articles are two examples) or has too little detail to be of much use ("Howto:Edit a livery" is an example of this) or that documents work flows that are clearly not best practices (the bump map wiki article in an example of this). Personally I don't care where this type of thing gets documented as long as it gets documented. So if there is a better place than the wiki by all means put the documents there. But what is that place?

Right now we have basically no best practices documentation for aircraft devs (at least nothing that lays out a detailed work flow with specific tool recommendations and information on how to use each tool to implement the work flow). Finding what little we have is difficult at best and because so much of it is outdated or is far from real best practices using what you find is a crap shoot. Sometimes you are golden and other times you are screwed In fact I believe it would be better to have nothing rather than articles that have incorrect/outdated/misleading information. I have seen some references to <fgdata>/Docs being the correct place for documentation like this but most of the documentation there is written more like an API doc for a library with a very narrow focus. Useful if you already know a lot about how things work but not very helpful if you are a noob since the docs there have 0 information about what are considered to be best practices or what tools should be used or what a best practices workflow looks like using a recommended tool chain or how everything fits together (with some amount of specificity) or how to do some very basic very common things so that noobs have some guidance about where to start.

In addition the ac3d exporter for Blender 2.5/2.6 is buggy and has trouble handling certain valid Blender files (It will move things around and/or flip normals rather than giving WYSIWYG results if your modeling work flow is not "correct" even if the Blender file is valid and does not contain anything that ac3d can't handle). It appears that these are known issues with known workarounds but none of this information is documented. So the unwary run into these issues and end up having to do a bunch of extra work that could have been avoided if the correct Blender workflow for this was documented. A better solution (than documenting the workarounds) would be to fix the exporter issues so that it correctly handles all valid Blender files and gives true WYSIWYG ac3d exports up to the limitations of the ac3d format. But I would be happy to see documentation of the recommended Blender workflow to avoid the exporter issues.

Not trying to point fingers here. The documentation issue is a systemic one that is negatively affecting a lot of areas in FG beyond just aircraft dev docs and is something that needs to be addressed. Either we determine that the wiki is the correct place for this stuff or we designate another place. Then we need to put processes in place to allow for the creation and maintenance of documentation in whatever location is selected.
hvengel
Retired
 
Posts: 1127
Joined: Sun Dec 24, 2006 5:35 am
Location: Minden Nevada

Re: Beechcraft b1900d template

Postby Buckaroo » Mon Aug 18, 2014 10:56 pm

Documentation can prove very unrewarding compared to other more visable or immediate efforts.

I wrote an extensive guide and reference to YASim, taking many hours away from my personal life and other projects, researching each portion to the best of my ability and experience, and took great care to make it organized and readable. I've tried to make it known that it exists without being too self-promoting. And yet I have received almost no feedback on the guide. It gets a brief mention at the bottom of the Flightgear YASim wiki article. My forum post promoting it in the Flight Dynamics Model section was not worth "sticky" status. I fear many users of YASim don't even know about it.

Perhaps the wiki is the better place for such things. But then authors lose control over the writing, style and content, and, for what it's worth, they also lose the recognition for their work, which can be a powerful motivator for continued document maintenance.

Most people are not writers and have never put together a major documentation effort. I think many people underestimate how much work such a project can be, and the rewards are far less than the raves received for beautiful scenery or a highly detailed aircraft.

-Buck
Callsign: Buckaro(o)
Author: Lockheed 1049H Constellation, Grumman Goose, MD-81, Edgley Optica, Velocity XL RG, YASim Guide
User avatar
Buckaroo
 
Posts: 475
Joined: Fri Jan 18, 2008 7:45 am
Location: Bloomington IN USA
Callsign: Buckaro(o)
Version: 2.10
OS: Windows & Linux

Re: Beechcraft b1900d template

Postby Johan G » Tue Aug 19, 2014 12:44 am

Buckaroo wrote in Mon Aug 18, 2014 10:56 pm:Most people are not writers and have never put together a major documentation effort. I think many people underestimate how much work such a project can be...

Indeed. I have found that even writing relatively short good article usually takes more than a couple hours. And that is only the very writing portion. By "writing an article" I mean writing and saving nearly the complete article on the first saved edit. (Hint: I use preview a lot).

I have to confess though: I am a bit pedantic. ;)

We are getting way off topic... :oops:
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6634
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Beechcraft b1900d template

Postby Gijs » Tue Aug 19, 2014 10:18 am

Hi,

Most of the articles have been written a long time ago with a specific user base/case in mind. If you expect to read something else in an article, there's usually a mismatch between your expectations and the intent of the writer(s). Does that make it a bad article? No. The livery editing article for example was never written to be a definitive guide on how to UV map an aircraft. If you expecting to find that kind of information there, you're guaranteed to be disappointed. You could argue whether that should be blamed on the article, the title, the place/kind of links to the article or maybe even the reader himself though...

hvengel wrote in Mon Aug 18, 2014 5:39 pm:documents work flows that are clearly not best practices (the bump map wiki article in an example of this)

Please correct the information if you find anything wrong. At the time it was written, it was considered to be a good work flow, but that may have changed nowadays. Just reading over such texts, noting they are wrong and then moving on won't get them fixed by magic. It's essential for a wiki that readers participate and help keeping information up to date and correct.

Right now we have basically no best practices documentation for aircraft devs (at least nothing that lays out a detailed work flow with specific tool recommendations and information on how to use each tool to implement the work flow).

That's a tough one. As with anything, there are dozens of routes to arrive at the same destination. For people familiar with Photoshop, it makes no sense to spend time mastering GIMP, just because a wiki article tells them that GIMP is to be used. Same for Blender/AC3D/SketchUp/3DSmax. That's probably the reason why you'll find that many articles are rather general, trying to suit as many different readers as possible.

Buckaroo wrote in Mon Aug 18, 2014 10:56 pm:It gets a brief mention at the bottom of the Flightgear YASim wiki article. My forum post promoting it in the Flight Dynamics Model section was not worth "sticky" status.

If you would've asked I would have pressed the button (just did). I don't ask myself the question "Should I stickify this?" with every post I read, so suggestions are always welcome. Self promotion is essential in our project and by no means selfish. Please add a link in whatever wiki article you consider relevant!

Cheers,
Gijs
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9545
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Beechcraft b1900d template

Postby hvengel » Tue Aug 19, 2014 5:35 pm

I agree that a lot of the docs that exist are not intended to be definitive guides but rather generalized overview articles. I didn't expect to find detailed UV mapping docs in the livery editing article. This was the article that was suggested as the place where the workflow being used for the topic of this thread should be documented and my point was that the livery editing article was at best a poor fit as the focus was completely different. So basically we are in agreement here but I probably didn't make things very clear and for that I apologize.

Eventually I will correct the reflection and bump map wiki articles but first I have to be far enough up the learning curve to know what these articles should say to actually document something close to best practices. At this point I have some areas of confusion and uncertainty but also a lot of ideas about what these workflows should look like and this makes tackling these articles a real challenge since I don't want to make things worse by putting new but still bad info onto the wiki.

You are correct that aircraft devs can and do use a wide range of tools chains to arrive at (nearly) the same result and that this makes the documentation process much more difficult. But the basic workflow for all of these tool chains will have common elements/processes. The way to solve that is to document a generalized workflow and then document tool specific processes for implementing each part of the workflow. We might start out by documenting the most common tools (Blender, Blender add ons, gimp, meshlab...). Then someone who uses some other tool chain can add info about how those tools can be used to do the same things.

I can move back and forth between Photoshop and Gimp for generalized image work and doing basic texture work in either is not an issue for me. This is probably true for most users and for those where this is not the case there is lots of on line help for both tools. Both tools allow for creating normal maps (Gimp uses an add in - not sure about Photoshop) and this is a very specialized activity where I suspect that the workflows in each tool are different and this is an area where most aircraft dev noobs, even if they have lots of experience using either graphics editor, will have very little experience. This is one area where having some detailed documentation would be very helpful. The point being that we don't need to document general very common usage (IE. creating a basic texture) only those things that are very specialized (at least initially).

The bump map article does have info on how to use the Gimp normal mapping stuff and it is enough to get started. But after playing with it I concluded that the techniques it is using are far from optimal and do not provide a generalized solution. For example it is not possible to have deep (very high) and shallow (not very high) features in the same normal map using the techniques from the wiki article and the technique used to create rivet heads is very crude at best and there is nothing about how to create normal maps for things like screw heads, Zeus fasteners.... After doing some normal maps with Gimp I have some ideas about what constitutes a good (perhaps close to best practices) workflow but I need to walk through that workflow and verify that I am on the right track before updating the wiki and it will likely be a number weeks before I can do this.

I agree that this is off topic since this thread is about the b1900d template/paint kit. But the off topic part is related since we are asking if it is possible to document the workflow/processes used to create the template/paint kit. So it is not totally off topic but should probably be in another thread.
hvengel
Retired
 
Posts: 1127
Joined: Sun Dec 24, 2006 5:35 am
Location: Minden Nevada

Re: Beechcraft b1900d template

Postby zlsa » Sat Aug 23, 2014 11:08 pm

Buckaroo, I use your guide as my reference when using YASim. I haven't sent any feedback because I haven't found anything wrong yet... :)
zlsa
 
Posts: 145
Joined: Fri Feb 14, 2014 3:29 am
Callsign: N275A
Version: 3.5 git
OS: Linux

Previous

Return to Liveries

Who is online

Users browsing this forum: No registered users and 1 guest