search

sidney-eliot / 3d-artists-handbook

Covers all stages of the 3D creation process, as well as the theory side of things. Helpful for 2D artists as well.
https://sidney-eliot.github.io/3d-artists-handbook
63 stars 7 forks source link

Possible duplication in the Project File Structure in the "My Setup" page #6

Open sugan-reden opened 5 days ago

sugan-reden commented 5 days ago

Hi!

I just found your site through the Quartz Showcase, and as both a 3D Artist and a programmer/game dev myself, I was quite happily surprised. Truly a humongus treasure trove. A huge thanks for your tremendous work, it will definitely prove useful to me in the future.

Now onto the issue at hand. I may be wrong here, but like the title says, there seems to be a typo/duplication in the Project File Structure presented. Unless, that is, you do really use a file structure with two directories named "Blender"? If it is so, then I would like to inquire about the reason, by curiosity.

image Included this for good measure.

Sidenote: This makes me think there may be another typo in the hardware section below, in the Huion Kamvas point, currently named "Kamas".

Out of context, but related: Also, forgive me as I have not read all of it yet so the following may come out of ignorance, but I would like to know how you handle projects that are multidisciplinary, in terms of workflow. For example, projects that go through the whole suite/process of software in production. Do you leave to them to each their own software directory, or have a temporary file transfer/conversion directory to transfer files to other software?

I would also like to know what the nesting level under this looks like (Level 2/3?). And, as a suggestion, what would you think about including example/dummy files to show an example of how you organize your files in directories further below. Something like this perhaps:

Modelling-Sculpture
L____ Blender
         L_________ example1.blend

Thank you for reading me :) And good day to you ☀️

sidney-eliot commented 5 days ago

Hi there, first of all I'm happy you took the time to comment about this stuff. Working on this handbook which over time has become quite a big thing, means that many mistakes will go unnoticed by my two eyes, especially when spending a lot of time working on the pages, basic mistakes start to become drowned out. The things you mentioned should now be fixed / improved in the live version of the handbook.

Also because of your other question, could you elaborate. When working between modeling software like Blender, ZBrush, Maya and ZBrush iPad I use one-click solutions in the form of transfer add-ons, more on that here: https://sidney-eliot.github.io/3d-artists-handbook/model-creation/workflow-between-zbrush-and-blender. For other software like Marmoset or Unreal I would have folders similar to what is now in the updated example.

If you have any further gripes or suggestions for the handbook, I would be happy to hear them. You can either create an issue as you have here, or write me on discord, which is probably better for back and forth conversations (my discord id is: "epicrex")

sidney-eliot commented 5 days ago

I just noticed that I might have gone a bit overboard on the example and it might now be hard to read. I'll maybe think of a cleaner way to show the folder structure.

sugan-reden commented 1 day ago

Hi, sorry for taking my time to answer, this week was crazy.

The things you mentioned should now be fixed / improved in the live version of the handbook.

That's great! I just took a look at it, and I think it's going in the right direction.

For other software like Marmoset or Unreal I would have folders similar to what is now in the updated example

Don't worry, this was indeed what I was wondering about. I believe that in the previous version, I didn't see any "transfer" folders for software that don't have a great import/export compatibility plugin/add-on. That said, based on the new structure, I'm guessing you leave them in their respective software directories, in a "... Output" sub-directory, is that correct?

If you have any further gripes or suggestions for the handbook, I would be happy to hear them. You can either create an issue as you have here, or write me on discord, which is probably better for back and forth conversations (my discord id is: "epicrex")

Understood and noted, although I like leaving issue-related discussions on the repo of choice, for records, availability to others and posterity, I don't mind either way. I don't use Discord very often these days, but I'll look into getting back into it.

I just noticed that I might have gone a bit overboard on the example and it might now be hard to read. I'll maybe think of a cleaner way to show the folder structure.

I thought about this too. In my mind, I have two suggestions.

Suggestion 1

Maybe splitting the top Projects directory and an example-project's directory into two sections?

Like so:

Section 1 Projects Root Directory or Project Main Folder (or what you feel is best)

Projects/
├── Character Projects
├── Creature Projects
├── Environment Projects
└── Studies

Section 2 Example Project Structure (or Character Example Project?)

Character Projects/
└── Astro Girl/
    ├── Reference/
    │   ├── AstroGirl.pur
    │   └── ...
    ├── Textures
    └── ...

Suggestion 2

Maybe it's just me, but I can't seem to find the source files so I don't really know how you made it, but is there a way to possible clean the tree structure?

You probably already thought about this too. But I find the branches quite jarring, since they all look like they're starting from the root ^^. I'm curious, since I haven't got to use Quartz yet, could that be the Quartz renderer acting up?

My suggestion would be to perhaps put it into a code block (or literal/verbatim block), but that might make you loose the emojis :(.

Misc.

Related, but not totally directly. Do you have a rigid file name structure? Like do you use pascal case for everything? Do you blend it in with kebab or snake case? Or do you use camel case for 3D-only files like some are wont to do?

If you do, what would you think about adding it? And describing your thought process on how you use it, and why you prefer it the way you do. Or if you're flexible to the needs of the project/company's already placed convention naming system, etc.

sidney-eliot commented 10 hours ago

Yeah I think you're right with this being better via issues. I don't have much time today, but I can quickly answer your last question.

I very much try to never ever touch my C disk as I hate how windows clutters it up by automatically creating files and installing things into it and how folders like "Program Files" have a spacing. For my PC I mostly keep everything PascalCase and kebap-case for my NAS. But in both cases I often switch over to Camel Case with spacing at, or close to file path endpoints. Only ever of course if the software that will be using that doesn't have problems with it.

This is something I have thought long about in the past and been on the fence for quite some time, thinking that it might be better to keep everything snake_case or kebap-case. But I eventually settled on a mix of what I mentioned above as I thought that there will anyway be some files that have spacing so why not give my eyes the satisfaction of nice folder names in non critical areas. It can make navigating around in terminals or using scripts a bit more of a hassle, but I find it to be worth it.