Policy Review 3D modeling for CAP

[paintseagull]

6th generation Pokemon games have moved from pixel to 3D graphics. For CAP 18, the first project of Gen 6, we did not attempt to change our usual procedure to include 3D models, since PS was still using sprites and the XY sprite project was in full swing. Now, though, animated gifs of these models have been extracted from the games and are the default for PS. There is a definite interest in making models for our CAPs, and if we did, we could potentially create animated gifs in the same style to be used alongside those in PS. We have adopted all other mechanics changes in Gen 6, so it seems only right that we should at least open the discussion for creating rendered images made from models of our CAP to mimic the graphics of real in-game Pokemon.

Thanks to Chaos Wolf and Yveltal, who are both in school for 3D modeling, for helping me with this OP. They're the resources for information in this thread and should be able to help us get started with this project if we decide to go forward with it, as well as with the policy.

------------------------------------------

Proposals:

Sprites: Keep the current sprite contest as it is, as long as we have willing participants. Making 3D models will NOT affect the Sprite submissions or polls.

3D Option 1: We will hold a contest for fully finished 3d models, submitted as transparent gifs of the rendered model with a front view and a back view. It will take place immediately after the art poll (same timeline as the Sprite contest currently has).

3D Option 2: We will open a thread for collaboration on a 3D model with an unrestricted deadline, but a goal of finishing at least a static rendered pose by the start of the Playtest.

3D Option 3: We will open a general collaborative thread with no particular timeline with the goal of modelling all CAPs, with priority on the newest ones.

3D Option 4: No 3D models for CAP. Sprites only.

edit: Clarification: the Sprites proposal is separate from the 3D proposals. The 3D proposals are all alternatives for each other.

------------------------------------------

Modeling Information/FAQ:

What does 3D modelling entail?:

• 3D software (Blender - blender.org - is one that's freely available)
• Making a wireframe model in 3 dimensional space according to a concept drawing
• Creating a coloured texture layer (called UV map or UV grid)
• Setting up the light source / light environment and surfacing
• Rigging the model (basically - give the wireframe a skeleton)
• Animating the model
• Rendering the model, exporting to transparent gif at an appropriate viewing angle (front and back)

How long will it take to create a model?

• The wireframe step is strongly dependent on experience and design complexity. As little as a few hours, up to 30 hours.
• The UV map stage is much quicker. Pokemon use basic flat colours with little or no texture and little detail. 2-6 hours
• Rigging can involve a lot of trial and error and may take a few days to complete
• Animating can be tedious and also involve trial and error. Can also take a few days.
• For reference, one spriter estimated 2-10 hours to make a CAP sprite. Animating a sprite also takes about this long again. Modeling will likely require more work hours than spiriting.

------------------------------------------

What we need to address in this topic to inform our decision and to expand on the above proposals:

- Should we collaborate? Wireframe modeling is not inherently collaborative, but rough work can be passed along for approval and tweaks like in the XY sprite project. Once a wireframe is finished, the rigging and UV map steps can be completed concurrently.

- Should lighting be standardized? If we want to mimic the Pokemon style, some experienced modelers can set up a standard CAP lighting environment for us to use. This would require that people submit their models in a standard format and the modeling team finalizes with our standard lighting setup , or that we make the environment preset available if possible.

> Yveltal: "it's smart to have preset lighting and shading modifiers in a specific program, if you want everyone to have the same kind of cel-shaded plus an outline look to their finished product"
> Chaos Wolf: "should be usable across models so long as models are all placed in same spot." "once we have lighting already set up, it's just a matter of putting the model in the center of that, it's like having a backdrop and light set for photos, just need to adjust for height."

- Do we need anything new from art submissions?

>Yveltal: "It would help to have multiple views for modellers to use as reference: a neutral-positioned front view and side view."
>Chaos Wolf: "Supplimentary material is very important (..) i.e. front T pose, Side w/o arm, back T pose. This is so you can model based on a static position."

Should this be up to the artists, or be assigned to a skilled volunteer just before starting 3D modelling? Or is it up to the modellers to create these?

- 3D models for previous CAPs:
How necessary is this? Do we feel that we can't move forward with CAP models without a commitment to make old CAPs? Or can we just start now and have old CAPs be done as personal projects by people who want to do them?

- Recruitment:
A few of our current CAP artists have expressed interest in learning Blender for this project. The learning curve on these programs is quite high, so it may take a few attempts for new modelers to be able to produce something of a high enough standard quickly enough for a submisson/poll type format. We may want to consider how we can advertise this to outside sites such as DeviantArt. We can also start a thread in Smeargle's Studio - a type of 3D modeling bootcamp to train interested artists up on Blender.

- Submission format:
This depends on how we decide to proceed with collaboration vs submission/poll. The contest could have people submit finished animated gifs. If we plan to use a standardized lighting setup, a standard file type that can be used by various kinds of 3D software would need to be used (.obj for example) as a submission format. This could also work if we want people to submit wireframes or wireframes + UV maps. In the case of 3D filetype submission, people would need to create previews to show people in the thread - this could be by screenshots or by exported rendered images.

------------------------------------------

Okay, this is a lot to take in, so feel free to focus on small pieces at a time. We should start from a basic overview of how we'd like to do this (see: Proposals) and afterwards gradually work through the details. The details are included in the OP now to inform your decision on the proposals and to give you an idea of the implications involved in the various proposals.

 

[Vryheid]

As someone who uses the CAPmons on a regular basis... I personally don't really care one way or the other if there is a 3D model behind them. The sprites for each CAPmon are pretty iconic by this point, and I don't feel like my enjoyment of the meta is hindered in any way by the sprites not matching the normal mons.

That being said, there is inherent value in building CAP's legacy by keeping our finished products looking up to date. Animated 3D models definitely have more of a visual appeal to a lot of players than the old 2D sprites, and allow for a greater amount of expression in each design. While this really isn't going to have any impact in the CAP-making process, it would have an impact on the interest in the CAP meta, which in turn leads to more interest in future CAP projects on the forum. Therefore, I'd be primarily interested in 3D Option 3 since the process wouldn't really feel complete until ALL of the CAPmons have gotten the treatment.

I have had some experience with 3D modelling and animation in the past, mainly using 3ds Max, but not through Blender- if this program is required I'd have to definitely learn how to use it before getting involved. Let me know if there's some sort of "bootcamp" involved, I'd be interested in helping out there.

 

[Quanyails]

General thoughts on where 3-D models should go in the CAP process:

PS! still uses sprites alongside 3-D models, as evidenced by the teambuilder and Pokedex. I don't think we need to eliminate sprites entirely, especially since sprites are still a good backup if there isn't interest or labor dedicated to making models.

We should, in my opinion, have 3-D model submission be part of the CAP process, alongside sprites, instead of having an open thread. More people follow the CAP forum when a CAP is currently in process, thus garnering more interest and contributions.

With those thoughts in mind, 3D Option 1 looks to be the most appealing to me.

--

Individual questions:

Should we collaborate?
Initially, I would say no. The X/Y Sprite Project tries to do its darnest to make the best Pokemon sprites on this side of the internet, but it suffers from the problem of 'too many chefs'. The leaders of the project have their own idea of what makes a sprite better, so a sprite gets passed around back and forth between various members for QCing and rarely gets complete approval and completion. Even after a sprite is approved, there is typically another member who does additional QC and causes someone's sprite animation to be obsolete. Making a contest out of 3-D models is sure to give us results rather than meandering to incompletion.

Should lighting be standardized?
Yes. Unlike sprites, where shading is determined primarily by the artist, 3-D models are shaded using mathematical formulae. There is consistency here that does not require artist subjectivity. Is there any way to pull the lighting style used from the games, or will we have to interpret that to start with?

Do we need anything new from art submissions?
It would be nice to have front/side views of a design, but given my experience, artists would need a 3-D model to start with to perfectly capture a design from various perspectives. In other words, while multiple views would be nice, it burdens the artist to be flawless with perspective and proportion. I believe Pokemon creates 3-D models from 2-D drawings and sprites, with varying degrees of accuracy, depending on the popularity of the Pokemon. Supplementary drawings from various angles would be great, but I don't think it should be urgent or required.

3D models for previous CAPs:
If there is interest and results, great. If not, we can make do with models for Gen. VI CAPs only. A similar sort of thing happened with Gen. V-style animations (although I blame my selective motivation for that); Gen. V sprites got animations, but the Gen. V revamps of Gen. IV CAPs did not. That worked okay and doesn't stress modelers to go back and revamp everything.

Recruitment:
Yeah, the previous hopes of making CAP models would only work if we have willing modelers. The most I've seen for CAP models is Wyverii's untextured, unrigged sculpt of Krilowatt. I'd definitely like to broaden interest and see more definite model results. Both reaching out to dA and opening a 3-D modeling thread where people can post their works sounds great.

Submission format:
I'm divided on this. On one hand, GIFs are finished products, removing the need for additional modeling steps. On the other hand, the 3-D files give modelers breathing room to make any changes in case Game Freak changes something in the future (new poses or shading, I'm thinking). I suppose I'll have to be persuaded through an external source on this matter if I am to make a decision.

 

[paintseagull]

I'm posting this on behalf of Layell who has lots of experience with the XY Sprite project and implementing model renders and sprites into PS. The following is a direct quote from his pm:
-------------------------------------

On Collaboration: Despite what others may believe the sprite project really has only 6 influential artists at the chef station, we can consider the rest kitchen support staff. While 4 alternate between scratch/colours/QC/style, the other two animate which is more than reasonable. Revisions taking place only when necessary due to new information (backs weren't as we expected, shiny colours screw us over, none of the problems CAP has). However modelling/rigging/animating/textures take much more time, and more than that it is unreasonable to expect a singular effort reach a satisfactory level compared to the actual models, whereas it is feasible to expect the same with sprites. When a solid leadership structure is in place combined with the expectation of what needs to be made there is not going to be a problem with collaboration on art projects.

On implementation: In an effort to reduce file size of the model renders each gif is put through a colour reduce that places only 16 colours (some like Xerneas and Gyarados Mega I believe do not have this). This is a simple Photoshop procedure but necessitates the need for gifs as part of a submitted final product. Futhermore I would expect all gifs to be 100 kb to no more than 300 kb after optimization. The average should be at the much lower end of that spectrum. Anything risks causing lag and objections from myself or upper PS team. But we can work to lower frames and work towards suitable file size if need be.

I would also expect models to be in an available format in some way in the event that model style changes in gen 7.

Even if animation were to not occur right away with models it would not be unreasonable to have a one frame gif of the model until animations were to later occur. This may be feasible during the conventional CAP process.

Also we'd need the actual model files in the event that someday we can implement actual models over renders on PS/Smogon

On Art: Yeah multiple views for sure, artists ought to have done fronts and backs a long time ago imo.

On Style: Kaphotics and Zhorken both seem to be able to get textures, and maybe even models soon, as perhaps the rest of Project Pokemon. I don't know the exact progress on this but this may be helpful to CAP in the near future.

On Timing: Keep sprites within the conventional CAP structure, keep models within a flexible time frame. At the end of the day however it should be those doing the work that have a greater say in the exact structure. But having 10 or so people put countless hours into a model then compete for votes I believe will cause a quick burn-out. After your first attempt then take another look at how you think models should be added.

 

[HeaLnDeaL]

Regarding the proposals, I think my preferences lie somewhere between options 1 and 2 (though I’m definitely not opposed to the older CAPs having models, too). A lot of the artistic (as well as the competitive) components of CAP are done in a contest-like atmosphere, with options being voted upon. In the end, I don't mind collaboration all too much either, but having a fully collaborative effort where all of the contributing artists make only a single model seems to be putting a lot of power in the hands of those who choose to participate. Without some form of options and voting, it means that non-artists might have little to contribute when it comes to a 3D model and it could be harder for them to voice their opinions. On IRC, there was some talk about having "teams" of artists compete to, in which multiple collaborative models would then go up in the polls. This would probably be something I would like to see, but I do recognize that it might be difficult to get enough artists for different teams, and that if a few members of one particular team don't pull their wait then the talents of other members might not reach fruition... In the end, I'm torn between a complete collaborative process where we will have a lot of talent working together, or having some sort of more competitive process with multiple models submitted and some form of poll/voting.

And of course, I agree that if any models are made, it shouldn't affect the sprite process (even if we decide to allow models, we should still have sprites).

There's a lot to take in and consider from the OP, but there is one of the details that strikes me the most, and I want to comment on it before I forget:

- Do we need anything new from art submissions?

>Yveltal: "It would help to have multiple views for modellers to use as reference: a neutral-positioned front view and side view."
>Chaos Wolf: "Supplimentary material is very important (..) i.e. front T pose, Side w/o arm, back T pose. This is so you can model based on a static position."
Should this be up to the artists, or be assigned to a skilled volunteer just before starting 3D modelling? Or is it up to the modellers to create these?

I do not think that art submissions should be required to have anything extra that what they have now. I definitely think it should be up to the modelers/spriters to create the extra details not seen in the official artwork's pose. If different angles had been standardized/officialized for the Volkraken art, then I likely wouldn't have been able to add the extra photophores that made up a second false-face on my back sprite. I think standardizing the general layout of multiple angles for the winning art submission would limit the creativity of spriters and modelers alike. Now, if we end up with some sort of "fully collaborative" 3D modeling process, it might be trickier to go about this, since everyone would have to agree on what the different angles should generally look like...

So, if there will be a competition at all among models, I don't think that other views/angles should be officialized, and that they should be up to the spriters/modelers.

However, this does bring up another issue; if we have sprites and models, and no official back/side views, then who gets to decide the other angles; the spriter or the modeler? I would assume that the sprite stage would get done first, and thus spriters would likely still have more control over back views (assuming different angles aren’t mandatory in the art submissions). However, this could result in a difficult time for some modelers, who would have to go back and make changes after the winning sprite is declared. Requiring different views/angles in the artist submission stages would help solve this, but as Quanyails mentioned, this might require such submitters to have a greater understanding of form and perspective. If a design with multiple views that aren’t 100% compatible in a modelled form ends up winning, then it could make modelers have a challenge balancing the details out. Realistically, I would hope such things would be minor and able to be accommodated for; even in the current sprite process there definitely is some wiggle room for spriters.

So, there are definitely pros/cons for having artist submissions include multiple angles. It might help the process flow better, but it limits creativity of the spriters and modelers. I realize that I am somewhat biased on this matter, since I took a fair amount of creative liberty with my back sprite for Volkraken. Do we want a process where this creative liberty is still as open? Or do we want a process that consolidates the parts and allows for different angles to be decided upon earlier, thus allowing spriting and modeling stages to begin at the same time with a more clear frame of reference on what the art should be like?

And to briefly address lighting; yes, I think standardized lighting is a good idea, as it helps create a uniform feeling among the mons. Also, a sort of boot camp for 3D modeling would be very much helpful.

 

[Chaos Wolf]

Looking over the OP, I'd recommend Sprites + Option 3. While new models have their place, rushing making the model or getting several and picking one would burn people out, make them less interested in working on this project. I'd actually advise something where you can turn the models overall on or off on the server, using either the gifs of the in game models and the models from this theoretical project, or the Sprites from the Pokemon XY Sprite project (used in the simulator already for team builder.

Regarding the Front and Side sheets, I see what HeaLnDeaL is saying regarding allowing interpretation of the design, however the modelling should ideally be done once the design and sprites have been finalized, and I'd advise collaborative endeavor. The Front and Side sheets give a benchmark for whether or not the model is on the right track. With more time invested into the project, you'll want it to be closer to the actual final product, both in sprite form and in the original drawing.

In my mind, the process for Modelling is independent of CAP project's timeline for the most part. With the project beginning at either Playtest or once the sprite has been finished (likely the latter more than the former.) An artist who has a good grasp on perspective takes the sprite and the model into consideration, and forms a character sheet of the design. from there, it is passed off to the modeler, who uses the sheet's dimensions for the front and side views to make the model and then prepare the UV sheet for the Texture artist. The Texture artist paints on the uv sheet using the colors blocked out by the concept sheet. From here, we have the model, painted and sculpted. Rigging and animating can be done with the unpainted model as well, as the texture will be a attachable PNG or TGA file. With the simple movements in the idle animations, ideally rigging and animation won't have any hiccups.

 

[DHR-107]

Agreeing with Chaos Wolf above. Option 3 seems like the best way to go for these models. Even if two people end up with different models we can still hold a vote and decide which one the community likes better from the available options.

There will have to be a collaborative edge to this regardless with the orginal Artist and the Spriter working towards a common goal (in making the model with the modeller). I know a few of the artists vanish after the art polls are concluded only to re-appear later on for the next project.

This all looks great to me paintseagull, I just hope that new contributors come in and work as hard for models as they do for sprites.

 

[Quanyails]

What I'm reading from other members seems to be those things that sound good in theory, but come with unintended realistic consequences. I'm drawing from previous examples to show some of those consequences that may hamper the otherwise ideal project.

CAP has previously finished an art revamp thread from Gen. IV to Gen. V, although not without concerns that may be repeated from Gen. V to VI. While the environment of the thread was open to independence and collaboration, what ultimately ended up happening was that while people decided to 'chip in' sprites, the bulk of the work fell on Wyverii. Collaboration, too, seemed limited to Wyverii + someone. CAP members had Wyverii to rely on to make sprites of implementable quality due to her leading presence in the thread. I consider this a good thing.

If CAP opens a general 3-D modeling thread, I figure we'd need another Wyverii to keep the project up to speed. If the thread is decentralized, I guess it could still work for making Gen. VI CAP models (I still have my doubts; nothing personal), but I don't think there would be enough motivation for more, such as revamping past-gen CAPs (Yveltal, Chaos Wolf, and others, I'd like you to show me otherwise one way or another).

 

[paintseagull]

Okay let's see. Let's focus on collaboration vs non-collaboration. This is definitely the biggest issue.

I agree with Quanyails in that a collaborative project leans heavily on its leaders, in which case the issue of burn-out isn't really solved, and could possibly be worse, depending on how many leaders we have and how dedicated contributors are. However, unlike the sprite revamp project, our goal does not need to be revamping everything if it's not feasible. As long as we do Gen 6, the rest can be done according to personal interest. For pre-Gen 6, an open collaborative thread is probably what we'll go with. I'm not sure if it'll go anywhere, but we can leave the possibility open.

We've decided that standardized lighting is a good idea, and that the separation of steps makes sense - one person doesn't need to do all of modeling, rigging, animating, UV sheet painting. The division of steps like this, though, as well as a standardized lighting system, will require at least one project leader to bring everything together.

"Collaborating" in the sense that the steps are done by different people and combined by one or two leaders is something I can imagine working. I am not sure about the modeling step itself though (just making the wireframe, no colour or rigging or lighting). What would collaborating just on this step entail? It seems a very personal endeavor, aside from maybe tweaking or QC by a second person. Tweaks or QC could be simply done on the chosen model by our leader if required during the lighting step. Allowing multiple submissions/WIPs without a contest at the end doesn't really solve the burnout issue either, it just makes it complicated as to how we choose which model to use.

So what I'm envisioning right now:
- Contest for wireframe models (submitters submit some sort of standard 3d model file as well as a rendered png/jpg/gif that shows one or two views)
- Leader puts winning model in lighting environment, exports UV map for painting.
- Someone on the modeling team / a volunteer / the leader paints the UV map
- Rigging/animation etc also done by other volunteers/leaders.

Rigging/animation could be a bit problematic with respect to leaning on the leaders, but I can't imagine running a contest for something like this, and it seems like the work could be passed around a bit more easily.

Experienced modelers, what do you think? Is it possible to pass a wireframe around successfully? I feel like this would be messy organizationally as well.

It was a good point too that right now spriters decide on some details, and so it only makes sense to start this after sprites are finished, unless we change something in that part of the process.

 

[Chaos Wolf]

Yeah, Quanyails is on the right track, there's a heavy risk of burnout if we leave it to one person.

In regards to your collaboration suggestion Paintseagull, I can see that potentially working, but I can't emphasize enough the strictness of maintaining what is the current version of the model. If two people change Version 3 into versions 4A and 4B, then there is no real way to combine their efforts effectively safe for just taking one model's changes and duplicating them on the other version. The problem can be far worse for Texture Artists and Riggers. If the Seams of the UV (where the model would be split across to fit on the UV Grid) are adjusted or otherwise modified, it can break the texture, and even adding a single edge loop breaks the work on the weight painting (how you tell the skeleton to move the model)

Relying on a good Rigger/Animator would be advisable, leader or elsewise. as for contests, perhaps example of previous work would be a good idea?

As for Passing around Wireframes, entirely viable so long as the current version is kept track of.

Perhaps the Contest for which Wireframe to use should have a lower polycount and show their Wireframes. We could decide on what is the better assembly then on being picked the modeler polishes it up the rest of the way. This lets the modeler risk less time, but also gives us an early look at what the model will eventually look like.

 

[paintseagull]

Posting this on behalf of Yveltal
-----------

if one person starts a modeling project, they can upload their file for other people to download and play around with. I think, when it comes to solely modeling something, one or two people should have a master file that gets updated until we agree that it's perfect, while others post screenshots of what changes, edits and concerns they may have about the wireframe/mesh. People who offer critiques by showing what they might do to the model shoulod only post images or a video instead of a new file, while the one with the master file may update both images and their latest iteration of the model for others to continue toying with.

I have one con with the idea that spriters/dot artists have some control over the design, and it may not apply at all, but professionally every art asset made in a game (2D/3D) follows concept art as closely as possible. The design only gets edited in the program medium within reason to make it look sensible on-screen, if there was some aspect of the design that didn't translate well from initial concept. I've already seen this done in past sprite contests, but i believe the modelers and dot artists should come to agree on the same editorial choices when creating their assets. At least, if not that, a modeler should be able to make a bare-bones model almost devoid of detail beyond the basic body shape and extremities that can be worked on to match edits made by the winning dot artist of the sprite contest.

 

[paintseagull]

I've been a tad busy and am going out of town tomorrow for a few days. I'll try to post something up quick via mobile tomorrow with my thoughts, but I think we should discuss a few more details before wrapping up entirely. I'm not planning to suggest any massive policy overhaul, this essentially won't affect any other part of the CAP process, so if PRC is wrapping up and this thread isn't finished I think that's ok, we can finish it up as the next CAP starts.

 

[paintseagull]

I've re-read everything and I have a good idea of what I think we should do. CAP is a collaborative project in the sense of democracy, and as a few people have pointed out, if we do not hold a contest with a vote, the non-modeling community will be shut out. I like the idea of holding a low-poly/low-detail wireframe contest (Submissions/Poll Format). We should aim to start Wireframe Submissions at the same time as Sprites. This might cause some conflict as spriters may want to try their hand at modeling but we may need to make that sacrifice.

The easiest thing to do regarding details that may not be obvious from the Main Design is to give modelers the same freedom of interpretation that we give spriters. It's up to the voters to decide which model is the best representation of the Pokemon. If the sprite poll occurs before the model poll, spriters retain their ability to decide colouring details. Non-colouring details should not really be a factor in low-poly wireframes and can be adjusted after the wireframe poll as needed.

Proposal:
- Wireframe Submissions for low-poly wireframes, to be submitted in an image (screenshots for example) AND a universal modeling program file type, goes up at the same time as Sprite Submissions
- Wireframe Poll goes up after Sprite Poll concludes.
- Adjustments/Detailing can be done by wining submitter and/or leader. UV map is then exported to be coloured
- Finished map and lighting environment are combined by the leader
- Animation done by volunteers on open timeline

 

[paintseagull]

Details that I still need help with:
- What is low-poly actually? Do all Pokemon have the same "poly count"? Do we need to restrict this?
- what is the universal format we should use?

Also, as for artist requirements, we should just leave it as it is now. I may just add a clause in the rules for art encouraging artists to create multiple views for the 3D process. (Just sketches should be fine)

(Sorry for triple posting, previous post was getting too unwieldy for mobile)

 

[DHR-107]

Okay,

I have been talking to Esmeya on #smogonwifi and they have agreed to help get some Poly counts for particular Pokemon. Kaphotics et al have made huge strides in taking parts of XY apart, and happily models are part of that.

I have a chat log (below) of me talking to them about the models and they ran some quick numbers on a few of the models that have available to them.

http://pastebin.com/JMSPjMM8

Bit long couldnt really quote it here.

The main thing to take from this:

DHR
On the models you have at the moment, whats the sort of rough number
11:33
Esmeya
oh
11:33
Esmeya
let me check
11:38
Esmeya
DHR - Skitty 5062, Hoopa: 6058, Metagross: 5930, Blissey: 5768, Wailord: 7040, Volcanion: 7095
11:38
DHR
whoa
11:38
DHR
holy crap
11:38
Esmeya
Seems smaller scale is 4900-5100, medium is 5200-6100 and large is breaking 6900-7250
11:38
DHR
thats so many more than I was expecting
11:39
Esmeya
Actually I should check Origin Forme Giratina..
11:39
Esmeya
actually wait
11:39
Esmeya
Volcanion is more than that
11:40
Esmeya
Polycount: 11468
11:40
DHR
O_O
11:40
Esmeya
with 7095 vertices [edited lol]
11:40
DHR
So anywhere between 5k and 12k polys?
11:40
Esmeya
yeah give or take

Esmeya is also providing me with a link to some of the models for you guys to use for playing/learning what the Pokemon models are like. All credit to Kaphotics for getting the models out! Thankyou guys for being awesome and continuing to help out everyone!

 

[paintseagull]

Thanks DHR!
Here is another pm from Yveltal with more info:

--------

The term "low-poly" can be used in one of two contexts. Either; 1.) You're using an object with UVs baked onto it from a higher polygon-count version of the same object to make it look more organic, or 2.) You have a game that runs on a poor engine and need lower polygon-count objects to function without having a baked texture from a high-poly version of the same object.

Bsking a high-poly texture onto a low poly object is another process separate from just creating a UV map for a singular object, so I'm willing to bet we'll be avoiding it. Making a low poly model as a best practice for our project is a good idea. Most game studios try to keep a low poly under 1000, but accommodate the mesh for animation and optimize on getting the most basic shape to make it easier to process in the engine.
From the prerelease conference for XY, they gave us a glimpse at Noivern's wireframe:

He's right about 1000, or just underneath/over that by a smidge.

As far as formats go, we should look to used the compressed versions of files for everything to go along with our low-poly practice. The final texture maps should be compressed into .targa files. For modeling, we should export work out to a .obj file, because a .obj can be read and loaded up in Blender, Maya, 3DS Max and all 3D game engines. A .obj isn't a compressed file, it's just the easiest to read if you're trading a file in between multiple programs.

Also, about the multiple views thing, whoever can make a front/side/top/back/bottom view of the winning design first will have solved the problem, and there isn't too much stress on making sure they're all to scale (though it helps a lot)

 

[DHR-107]

I decided to format it a little better than an IRC conversation, so:
Polycount - Fa no quad
Ditto - 1947*
Chimecho - 2235
Octillery - 2272 (Without full face)
Voltorb - 3112
Garchomp - 4304
Skitty - 5062
Ho-oh - 5496* (Without left thigh reflect and solid body inserted)
Blissey - 5768
Metagross - 5930
Hoopa - 6058
Wailord - 7040
Giratina Oirigin Forme - 9112
Volcanion - 11468* (Detachable hoses, jewels and tail)
* (poly 'range' low, mid, high - not including low poly force and as is when unpacked)
Below are wireframe examples of the most complex model so far, Volcanion. With front, back, side views. I detached and readjusted the hoses (crappily because I'm tired), so that you could see the inside as well as, disassembled the pieces that make up the entire model. Volcanion pulls the hoses apart to attack and with very little animation available for it I used what I could find to emulate the general height they would be in attacking position.
[If these are too big and obnoxious let me know]

In-game model, courtesy of Serebii

Wireframe ​

Any questions concerns etc let me know.

Esmeya has given me some more counts for various other Pokemon . They've also taken Volcanion apart and looked at how it may move. paintseagull, they have given me some of the models to play with if you want me to share them with you to have a nose around. Kaphotics is a legend as far as I am concerned atm haha :)

 

[Birkal]

This thread is up for you to conclude, paintseagull. Do as you see fit. Great work so far, guys!

 

[paintseagull]

Here's a further response by Yveltal :
------------------------

Nevermind the note I made about Noivern's actual poly count if Game Freak doesn't mind making models that are about 5000 on average. A 1000-2000 poly count model would really be the bare bones of a creature/object, as taught in-school. Chances are they let Pokemon in-game have 7000 some-odd polygons because there isn't a whole lot going on on-screen that the game has to process during a battle. Anywhere between 2 to six pokemon on screen, background, standing platforms, attacks, lighting, shading, textures and possibl a weather/other environmental effector means you're normally staring at about 60,000+ polys during a battle at most (in a 3-vs-3 or a hoard battle), so if Game Freak is doing it, I don't see the harm in letting people model within the 5000-12000 range for the sake of having a smoother texture.

We shouldn't really worry about getting a low poly model immediately. Most game artists will tell you, it's generally easier to sculpt a blocked-out model in ZBrush and wind up importing a high-poly model from there into a modeling program than it is to start off creating a model out of basic shapes. This means that, if Chaos wolf or myself were to start making something, the first pass would likely be high poly because it's easier to get the form you want when you have more polygons on an object to move around. Something like Charmander or Skitty could get a half-decent model with accurate proportions done in a few days, and something at Volkraken's complexity could get a block out in about a week, depending on the modeler's experience and time invested each day. Removing unnecessary polygons with the intent of getting something super low poly takes about a week, because the modeler has to consider where the splines and vertices are most important when every polygon counts.

 

[paintseagull]

OK, here is my preliminary "Wireframe Submissions" OP. Please help me refine and tweak this! I think the first time we do this it will be a bit of trial and error, but it'd be good for this to make as much sense as possible the first time around.

-------------
Part 14 - 3D Wireframe Submissions

Rules

• Wireframes will be created in 3D Modeling software such as Blender and must be saved in .obj format.
• Wireframes should be inspired by the winning design from the Art Poll and the Sprite Poll. It does not need to be an exact rendition of every detail of the design; "artistic license" is granted. However, drastic deviation from the selected art and sprite designs is discouraged.
• Wireframes should have polycounts to mimic Pokemon models in Pokemon X and Y. This range is approximately between 2,000 and 10,000 depending on complexity. Submitted wireframes may err on the side of low polycounts and may leave out some details (see below).
• When posting WIPs, please post screenshots or renders of your wireframe in a compressed image format such as jpg and host them on external sites such as imgur or puush. Please keep these images under 640 pixels in either dimension and under 200 kB.

Final Submission

All modelers must make a final submission post conforming to the following:

• The post must have "Final Submission" (in bold) as the first line, followed by up to three compressed images under 640 px in either dimension and under 200 kB. These images should give multiple views of the wireframe so that all the details can be seen.
• The post must also link to the .obj file of the wireframe, hosted externally on a site such as dropbox. No lighting, textures or UV maps should be applied to the wireframe in the .obj file. Submitters may instead send the .obj file privately to the Wireframe Coordinator.
• The submitted wireframe may leave out details and have a low polycount in the interest of saving time. The chosen wireframe will then be refined by the Coordinator and/or the submitter collaboratively.
• By making a final submission you agree to allow the modification of your submitted wireframe and for it to have UV maps, rigging and animation applied to it.
• Only make one (1) final submission post.

All legal final submissions will be included in the poll.

Advice for Modelers

• Show front and back views that mimic in-game battle perspective.
• Show hollow and skinned wireframe views in WIP posts.

Main Design
--insert image here--

Additional supporting material by the design artist (artist name) can be found here. The spiriting thread can be found --here--. Modelers are NOT obligated to use any design elements of artwork not represented in the Main Design. This includes details shown only in back views or other action poses by the design artist. The only official reference artwork for this project is the Main Design. Spriters have priority in the interpretation of details not shown in the main design -- it is encouraged but not required to refer to the winning sprite when finalizing model details.

--------------------

 

[Yveltal]

~I made it, I'm in the club~

I have a few notes about what to edit in PSG's first draft for the modeling competition.

Hide

Rules

• Wireframes will be created in 3D Modeling SOFTWARE such as Blender and must be saved in .obj format.(in 3D software, a file has to be exported into a new file to attain a .obj version of the modeler's work. A .obj is an iteration separate from the original file.)
• Wireframes should be inspired by the winning design from the Art Poll and the Sprite Poll. It does not need to be an exact rendition of every detail of the design; "artistic license" is granted. However, drastic deviation from the selected art and sprite designs is discouraged.
• Wireframes should have polycounts to mimic Pokemon models in Pokemon X and Y. This range is approximately between 2,000 and 10,000 depending on complexity. Submitted wireframes may err on the side of low polycounts and may leave out some details (see below).(Definitely try to express that a lower poly model is more preferable for reasons including easier downloads)
• When posting WIPs, please post screenshots or renders of your wireframe in a compressed image format such as jpg and host them on external sites such as imgur or puush. Please keep these images under 640 pixels in either dimension and under 200 kB.

Final Submission

All modelers must make a final submission post conforming to the following:

• The post must have "Final Submission" (in bold) as the first line, followed by up to three compressed images under 640 px in either dimension and under 200 kB. These images should give multiple views of the wireframe so that all the details can be seen. (The typical screenshots you would want to look for are a front, side and 3/4 view of the model at eye level. How do you feel about people creating gifs of their model slowly rotating around as an extra form of picture submission?)
• The post must also link to the .obj file of the wireframe, hosted externally on a site such as dropbox. No lighting, textures or UV maps should be applied to the wireframe in the .obj file. Submitters may instead send the .obj file privately to the Wireframe Coordinator.
• The submitted wireframe may leave out details and have a low polycount in the interest of saving time. The chosen wireframe will then be refined by the Coordinator and/or the submitter collaboratively. (Keep in mind that, if the modelers aren't considering what's easiest for animation, the most detail you'll be missing that's necessary for the rest of the process is probably going to be completely accurate proportions and entries in weird, non-traditional non-neutral poses. Unless this point was made to say that we will be accepting models with extraneous detail purposefully left out because of time constraints or a lack of knowledge as to what the dot artists were going to do to the design, in which case this needs more clarification.)
• By making a final submission you agree to allow the modification of your submitted wireframe and for it to have UV maps, rigging and animation applied to it.
• Only make one (1) final submission post.

All legal final submissions will be included in the poll.

Advice for Modelers

• Show front and back views that mimic in-game battle perspective. (This strikes me as odd. Ideally, the models will be in perfectly neutral poses, and this suggestion gives me the image of the Noivern mesh from that screenshot just floating mid-space at an angle. Having angled front and back views probably won't help much for composition's sake, unless the modeler is building their mesh to start in an alive idling pose, which isn't ideal.)
• Show hollow and skinned wireframe views in WIP posts.(This is normally a toggle in every 3D software's regular viewing mode. You can turn the mesh/polygon's viewability on and off for quick screencaps. This should be reworded to something like, "Show the model with the polygons toggled on and off. We'd like to see the wireframe and the full mesh", but maybe in better layman's terms, if it's still confusing.)

Main Design
--insert image here--

Additional supporting material by the design artist (artist name) can be found here. The spiriting thread can be found --here--. Modelers are NOT obligated to use any design elements of artwork not represented in the Main Design. This includes details shown only in back views or other action poses by the design artist. The only official reference artwork for this project is the Main Design. Spriters have priority in the interpretation of details not shown in the main design -- it is encouraged but not required to refer to the winning sprite when finalizing model details

Also, I'm glad that PSG is looking to have someone with a coordinator hat to double check the work of the winning mesh and make sure it's up to snuff. Given the expertise of those involved, I think that title should go to Chaos Wolf for our first time doing this, as he's most likely a faster modeler than me. I'd like to offer whatever notes I may have so that the model is ideal for rigging and animation.

 

[paintseagull]

Here's another iteration on the wireframe OP!

-------------
Part 14 - 3D Wireframe Submissions

Rules

• Wireframes will be created in 3D Modeling software such as Blender (open source), 3ds Max or Zbrush. The software must be able to export to .obj format.
• Wireframes should be inspired by the winning design from the Art Poll and the Sprite Poll. It does not need to be an exact rendition of every detail of the design; "artistic license" is granted. However, drastic deviation from the selected art and sprite designs is discouraged.
• Wireframes should have polygon counts to mimic the style of Pokemon models in Pokemon X and Y. These models have counts ranging between 2,000 and 10,000 depending on complexity.
• Wireframes should be created using a neutral pose. Rigging and animation will need to be done at a later stage, so keep this in mind.
• When posting WIPs, please post screenshots or renders of your wireframe in a compressed image format such as jpg and host them on external sites such as imgur or puush. Please keep these images under 640 pixels in either dimension and under 200 kB.

Final Submission

All modelers must make a final submission post conforming to the following:

• The post must have "Final Submission" (in bold) as the first line, followed by three compressed images under 640 px in either dimension and under 200 kB. These images should give a front, side and 3/4 view at eye-level. The 3/4 view can be adjusted to best show off your model.
• The post must also link to the .obj file of the wireframe, hosted externally on a site such as dropbox. No lighting, textures, colour, or UV maps should be applied to the wireframe in the .obj file. (Submitters have the option of sending the .obj file privately to the Wireframe Coordinator if they would prefer).
• Wireframes that have extraneous details left out or which are still works in progress are acceptable submissions. The chosen submission will be edited later for detail and quality control. At this stage, the focus is on proportions, shape, and an appropriate pose. If their submission is chosen, a modeler may continue to work with the Coordinator on their model during the Quality Control stage.
• By making a final submission you agree to allow the modification of your submitted wireframe and for it to have UV maps, rigging and animation applied to it.
• Only make one (1) final submission post.

If the Coordinator feels that a wireframe is not suitable to be rigged or UV mapped in the future, it may be disqualified. Otherwise, all legal final submissions will be included in the poll.

3D Modeling Stages

• Wireframe Submissions <- you are here
• Wireframe Poll
• Wireframe Quality Control
• Rigging
• Animating
• UV mapping

Advice for Modelers

Check out the thread in Smeargle's Studio for help and tips on modeling in general.

Main Design
--insert image here--

Additional supporting material by the design artist (artist name) can be found here. The spiriting thread can be found --here--. Modelers are NOT obligated to use any design elements of artwork not represented in the Main Design. This includes details shown only in back views or other action poses by the design artist. The only official reference artwork for this project is the Main Design. Spriters have priority in the interpretation of details not shown in the main design -- it is encouraged but not required to refer to the winning sprite when finalizing model details.

 

[paintseagull]

Here's a WIP for the Past CAPs modeling project OP. Yveltal I need your help with this specifically, everyone feel free to help as you're able. Suggestions for additions, changes, rules, stuff I missed, etc, are all welcome.

-------------
The CAP 3D Modeling Project

Goals

• Create static or animated 3D models of all previous CAP pokemon!
• Implement .gifs of these models on Pokemon Showdown
• Have fun! There is no deadline or requirement for us to do these models. There is no priority list for which CAPs to create first.
• Standardize our models so they look as close to the style of Pokemon X & Y as possible.
• Collaborate on the multiple aspects of modeling: wireframes, rigging, animation, UV mapping, lighting and texture.

*Note: Sprites are not being replaced! We are still making and using sprites in CAP.


Rules

• Wireframes should be created in 3D Modeling software such as Blender (open source), 3ds Max or Zbrush. The software should be able to export to .obj format.
• Wireframes should be inspired by the winning design from the Art Poll and the Sprite Poll. It does not need to be an exact rendition of every detail of the design, but drastic deviation from the selected art and sprite designs is discouraged.
• Wireframes should have polygon counts to mimic the style of Pokemon models in Pokemon X and Y. These models have counts ranging between 2,000 and 10,000 depending on complexity.
• Wireframes should be created using a neutral pose. Rigging and animation will need to be done at a later stage, so keep this in mind.
• When posting WIPs, please post screenshots or renders of your wireframe in a compressed image format such as jpg and host them on external sites such as imgur or puush. Please keep these images under 640 pixels in either dimension and under 200 kB.

Submitting wireframes

• For each CAP, only one wireframe will be listed as the official WIP or finished product.
• If you want to create a wireframe for a CAP which does not have an official wireframe yet, it's first-come first-serve. If someone's already started the wireframe for a CAP and it's been approved for further work by the Coordinator, then please work on another CAP or help with Quality Control.
• To "claim" a wireframe WIP, post some screenshots of your work and a .obj file. The Coordinator will then let you know if your wireframe is accepted as the official WIP.
• When posting links to .obj files of the wireframe, host them externally on a site such as dropbox.
• When collaborating with others, be explicit about who is working on which version of the wireframe when. The coordinators should keep the version and current modeler list (see below) updated.

Other stages

• Quality control - The coordinator(s), wireframe submitter and other collaborators (optional) will iterate back and forth on a wireframe until they feel it is suitable for rigging and UV mapping. It will be finalized and the UV map will be exported for colouring (??? Yveltal help)
• Rigging - Post if you want to claim something for rigging. Collaboration is possible.
• Animating - Post if you want to claim something for animating. Collaboration is possible.
• UV mapping - Post your WIPs or finished UV maps. The first acceptable finished map will be likely be accepted.

Advice for Modelers

Check out the thread in Smeargle's Studio for help and tips on modeling in general.

List of CAPs and status

• Pokemon || Wireframe status [Version # @ Current modeler] || Further status
• Syclant || Unclaimed
• Revenankh || Unclaimed
• Pyroak || Unclaimed
• Fidgit || Unclaimed
• Stratagem || Unclaimed
• Arghonaut || Unclaimed
• Kitsunoh || Unclaimed
• Cyclohm || Unclaimed
• Colossoil || Unclaimed
• Krilowatt || Unclaimed
• Voodoom || Unclaimed
• Tomohawk || Unclaimed
• Necturna || Unclaimed
• Mollux || Unclaimed
• Aurumoth || Unclaimed
• Malaconda || G0dsl4yer WIP [Version 01 @ G0dsl4yer]
• Cawmodore || Unclaimed
• Volkraken || Unclaimed

--------------------

 

[Yveltal]

I had all of this scrawled out on the back of a word doc that I printed. Here goes!

Here's another iteration on the wireframe OP!

-------------
Part 14 - 3D Wireframe Submissions

Rules

• Wireframes will be created in 3D Modeling software such as Blender (open source), 3ds Max or Zbrush. The software must be able to export to .obj format.
• Wireframes should be inspired by the winning design from the Art Poll and the Sprite Poll. It does not need to be an exact rendition of every detail of the design; "artistic license" is granted. However, drastic deviation from the selected art and sprite designs is discouraged.
• Wireframes should have polygon counts to mimic the style of Pokemon models in Pokemon X and Y. These models have counts ranging between 2,000 and 10,000 depending on complexity.
• Wireframes should be created using a neutral pose. Rigging and animation will need to be done at a later stage, so keep this in mind.We should always keep in mind that a neutral pose is different for each basic body type, but a neutral pose generally involves having the body and extremities in a position that's easy to get a number of different poses out of during animation. Humanoid designs should be modeled with their arms sticking out so that the body's in either a T-Pose or a relaxed T-pose, tails are to be modelled straight and with evened out geometry, and so forth. I can find a reference link for general body shapes and what their neutral poses look like.
• When posting WIPs, please post screenshots or renders of your wireframe in a compressed image format such as jpg and host them on external sites such as imgur or puush. Please keep these images under 640 pixels in either dimension and under 200 kB. This looks pretty feasible. We may want to keep a scale in mind for modeling as well. It doesn't really effect the file size, but downloading and importing each other's work is easier to do when the models are all at the same general scale size.

Final Submission

All modelers must make a final submission post conforming to the following:

• The post must have "Final Submission" (in bold) as the first line, followed by three compressed images under 640 px in either dimension and under 200 kB. These images should give a front, side and 3/4 view at eye-level. The 3/4 view can be adjusted to best show off your model.
• The post must also link to the .obj file of the wireframe, hosted externally on a site such as dropbox. No lighting, textures, colour, or UV maps should be applied to the wireframe in the .obj file. (Submitters have the option of sending the .obj file privately to the Wireframe Coordinator if they would prefer).If someone wants to, they should feel welcome to create a download link on an external site/blog for their files. I like this little line of easy-to-use HTML for such a case (http://www.wikihow.com/Make-a-File-Downloadable-from-Your-Website)
• Wireframes that have extraneous details left out or which are still works in progress are acceptable submissions. The chosen submission will be edited later for detail and quality control. At this stage, the focus is on proportions, shape, and an appropriate pose. If their submission is chosen, a modeler may continue to work with the Coordinator on their model during the Quality Control stage. Good idea to stress that anybody's model can win and that a high level of polish doesn't guarantee victory.
• By making a final submission you agree to allow the modification of your submitted wireframe and for it to have UV maps, rigging and animation applied to it.
• Only make one (1) final submission post.

If the Coordinator feels that a wireframe is not suitable to be rigged or UV mapped in the future, it may be disqualified. Otherwise, all legal final submissions will be included in the poll. I can already imagine a few basic unwritten clauses for disqualifying an entry, though it will probably only become an issue if there's ever a model that's just a nightmare to work with.

3D Modeling Stages

• Wireframe Submissions <- you are here
• Wireframe Poll
• Wireframe Quality Control
• Rigging
• Animating
• UV mapping

Keep in mind that mapping/texturing can begin at the same time as rigging, and can last as long as it needs to as a separate portion of the process up until the animation is good enough to render into a gif.

Advice for Modelers

Check out the thread in Smeargle's Studio for help and tips on modeling in general.

Main Design
--insert image here--

Additional supporting material by the design artist (artist name) can be found here. The spiriting thread can be found --here--. Modelers are NOT obligated to use any design elements of artwork not represented in the Main Design. This includes details shown only in back views or other action poses by the design artist. The only official reference artwork for this project is the Main Design. Spriters have priority in the interpretation of details not shown in the main design -- it is encouraged but not required to refer to the winning sprite when finalizing model details.

Here's a WIP for the Past CAPs modeling project OP. Yveltal I need your help with this specifically, everyone feel free to help as you're able. Suggestions for additions, changes, rules, stuff I missed, etc, are all welcome.

-------------
The CAP 3D Modeling Project

Goals

• Create static or animated 3D models of all previous CAP pokemon!
• Implement .gifs of these models on Pokemon Showdown
• Have fun! There is no deadline or requirement for us to do these models. There is no priority list for which CAPs to create first.
• Standardize our models so they look as close to the style of Pokemon X & Y as possible.
• Collaborate on the multiple aspects of modeling: wireframes, rigging, animation, UV mapping, lighting and texture.

*Note: Sprites are not being replaced! We are still making and using sprites in CAP.


Rules

• Wireframes should be created in 3D Modeling software such as Blender (open source), 3ds Max or Zbrush. The software should be able to export to .obj format.
• Wireframes should be inspired by the winning design from the Art Poll and the Sprite Poll. It does not need to be an exact rendition of every detail of the design, but drastic deviation from the selected art and sprite designs is discouraged.
• Wireframes should have polygon counts to mimic the style of Pokemon models in Pokemon X and Y. These models have counts ranging between 2,000 and 10,000 depending on complexity.
• Wireframes should be created using a neutral pose. Rigging and animation will need to be done at a later stage, so keep this in mind.
• When posting WIPs, please post screenshots or renders of your wireframe in a compressed image format such as jpg and host them on external sites such as imgur or puush. Please keep these images under 640 pixels in either dimension and under 200 kB.

You may want to add a note here that says something like, "no matter how much you've done on your own (modelling, texturing, etc), if our coordinator approves your file, it can be subject to editing at any level"

Submitting wireframes

• For each CAP, only one wireframe will be listed as the official WIP or finished product.
• If you want to create a wireframe for a CAP which does not have an official wireframe yet, it's first-come first-serve. If someone's already started the wireframe for a CAP and it's been approved for further work by the Coordinator, then please work on another CAP or help with Quality Control.
• To "claim" a wireframe WIP, post some screenshots of your work and a .obj file. The Coordinator will then let you know if your wireframe is accepted as the official WIP.
• When posting links to .obj files of the wireframe, host them externally on a site such as dropbox.
• When collaborating with others, be explicit about who is working on which version of the wireframe when. The coordinators should keep the version and current modeler list (see below) updated.

On this point, what do you think of allowing for a window of time for anyone to submit their work regarding a CAP that someone has applied to claim? Would it take away from the experience for a coordinator to choose the best model out of a few entries?


Other stages

• Quality control - The coordinator(s), wireframe submitter and other collaborators (optional) will iterate back and forth on a wireframe until they feel it is suitable for rigging and UV mapping. It will be finalized and the UV map will be exported for colouring (??? Yveltal help) I don't know how you have it planned, but I think that Quality Control should have its own revolving thread that has a post at the beginning that defines where we are on the current CAP being generated. I'd also like for this potential thread to operate just like an Art Submissions thread, in that people can only post a certain number of times. I feel like, if people can sit on their posts and flesh out their opinions, we'll have a better time learning together. Your terminology is also pretty much on-point.
• Rigging - Post if you want to claim something for rigging. Collaboration is possible.
• Animating - Post if you want to claim something for animating. Collaboration is possible.

For rigging and animating, I believe that approval to move forward should be granted partially in recognition of the applicant's skill and previous experience. I'd also like to eventually have a revolving group of people who would like to do these so more people get a chance at hands-on experience in these fields.

• UV mapping - Post your WIPs or finished UV maps. The first acceptable finished map will be likely be accepted. I have no problems with downloading and testing any and all texture maps submitted. My only winning condition so far is "whichever one looks the best when a cel shader is added to it wins"

Advice for Modelers

Check out the thread in Smeargle's Studio for help and tips on modeling in general.

List of CAPs and status

• Pokemon || Wireframe status [Version # @ Current modeler] || Further status
• Syclant || Unclaimed
• Revenankh || Unclaimed
• Pyroak || Unclaimed
• Fidgit || Unclaimed
• Stratagem || Unclaimed
• Arghonaut || Unclaimed
• Kitsunoh || Unclaimed
• Cyclohm || Unclaimed
• Colossoil || Unclaimed
• Krilowatt || Unclaimed
• Voodoom || Unclaimed
• Tomohawk || Unclaimed
• Necturna || Unclaimed
• Mollux || Unclaimed
• Aurumoth || Unclaimed
• Malaconda || G0dsl4yer WIP [Version 01 @ G0dsl4yer]
• Cawmodore || Unclaimed
• Volkraken || Unclaimed

I may be nitpicking here, but I would prefer a layout more like:

• 
  
  
  • Name of Pokemon

• -Wireframe status [version, current user
  -Texture status [version, current user]
  - Rig status [version, current user]
  - Animation status [version, current user]

For each of them.


--------------------

 

[paintseagull]

Yveltal

Current CAP Wireframe OP:

Regarding tips and tricks for things like how to make a neutral pose, scale, unwritten clauses that may disqualify and entry, etc: It might be good to write up a short list of tips and tricks for 3D modelling and either put them in the Smeargle's thread and link them, or put them in the OPs of the modelling thread under a hide tag. Would you be able to write such a thing up? I think we can move ahead without it, and go back and edit it in when we're able. If we include too much extraneous info in the rules they will become difficult to follow.

Maybe this would be more clear for the modelling stages explanation:

3D Modeling Stages

• 1. Wireframe Submissions <- you are here
• 2. Wireframe Poll
• 3. Wireframe Quality Control
• 4. a) Rigging / b) UV mapping (these are concurrent)
• 5. Animating (needs only Rigging to be finished to begin)

Past CAPs modeling OP:

Regarding: window of time to submit work: I don't think this is necessary, unless we end up with more contributors than CAPs to model. Since there is so much work to be done here, and since it is primarily for fun, having people compete against each other is perhaps a bit wasteful. We can revise this policy if there ends up being a lot of demand for people to model the same CAP, otherwise, it seems overly complex.

Regarding: Separate QC threads - I could see this being helpful, but this might be better to do via private message, lest we clog up the entire forum with modelling threads. I was imagining that there'd be at most 3 people QC'ing one model. I think it will be fine to just have these conversations in the one thread, since I don't expect we will be all that busy. Again, we can revise it if we find there's a need. I'd like to keep things as simple as possible to start.

For the above two points, we'll keep these suggestions in our back pocket in case we find we need them

Regarding: approval for rigging/animating/UV - sure. I'll leave it up to you to sort out how to approve people for these. I like the idea of encouraging different people to get experience.

How about doing something like this for the layout of the list of CAPs:

List of CAPs and status

• Pokemon || Wireframe status [Version # @ Current modeler] || Further status
  • Wireframe status [version, current user]
  • Texture status [version, current user]
  • Rig status [version, current user]
  • Animation status [version, current user]
• Syclant || Unclaimed
• Revenankh || Unclaimed
• Pyroak || Unclaimed
• etc....

• Malaconda || G0dsl4yer WIP [Version 01 @ G0dsl4yer]
  details

  • Wireframe status [version, current user]
  • Texture status [version, current user]
  • Rig status [version, current user]
  • Animation status [version, current user]
• Cawmodore || Unclaimed
  

Everyone else: Feedback still welcome and appreciated!