287 réponses à ce sujet

[MerricksDad]

 

Be sure to note the flying monstrosity in the background up by the turret...yup, a pink balloon elephant with little pink bird wings.

[3RavensMore]

You see!  I warned you!  Now you can't stop yourself.

[MerricksDad]

So back to all seriousness, I think I will be putting weapons on the back burner while I work on two things:

• Treebuilder script: specifically pine species
• Tileset tutorial for the new vault.

I find these two things are currently much more important to me than more weapons. The first being something I want to use to show something about tilesets.

 

After that, what I really want to do is go back and make some weapon sets, instead of just singles. I really need to tweak those orcish items first, but I know I won't get that done in time for the orc stuff CCC project. Not with everything else I am working on. I'd like to make a second weapons tutorial on creating multiple weapons at once from a single texture plate, and then making a similarly textured set from the lot. Complete with descriptions and why's of weapon rotation, transformation, and positioning.

 

Help me if you will, add to these lists:

• Polearm Types (which might include...)
• Farm Implements (like rakes, shovels, pitchforks, barn poles)
• Orcish Items (that set I ripped out of Skyrim)
• Crystals 1: Ice (add more variety of items to the ice cube set)
• Crystals 2: Demon Bone stuff
• Crystals 3: Corrosive green
• Crystals 4: Psi crystals and soul containers
• Primitive Items: Stone tools and makeshift orcish weaponry

I've already started a to-do list near the front of this thread, and I may put these categories up there instead if I can get enough items collected for them.

 

I'd also like to explore the boundaries of weapon numbers. What are those limits for the min-max range, and can we fudge them to make the toolset behave differently? I know the engine itself can take a lot of tricks, but can the toolset? I'd like to fully document what you can do there.

 

I may then move back to my spell vfx series that I started over a year ago. One was just getting started with animesh, while the other was more of a finished set that I intended to merge with other stuff I had made. It included some clones of infinity engine spell vfx. I'd really like to pick both of those back up, but especially the animesh ideas.

 

After that, I could follow animesh back to the tileset realm and make some flowing texture tutorials for water, lava, or recreate my lakeshore waves I did back in 2008. Man those were awesome. It took a span of 3 tiles out from the lakeshore tile and turned them into flowing water that constantly moved inland. I used them as border tiles with no edge tiles and it looked great. Drool.

[The Amethyst Dragon]

I'd also like to explore the boundaries of weapon numbers. What are those limits for the min-max range, and can we fudge them to make the toolset behave differently? I know the engine itself can take a lot of tricks, but can the toolset? I'd like to fully document what you can do there.

 

I know that one can push the upper range to 255 (part 25, color 5).  I personally use (or open up) colors 0-9 for all part numbers up to 24.  I have not yet tried pushing the range down from the standard 010 to 000, but it might work.

 

The only issues with using the extra "colors" that I've encountered are:

- You need model+icon 010 to open up color 0, and 019 to open colors 5-9 (might need 015 to 018 as well, not sure).

- If you start using color 0, you need to have a model+icon for color 0 for every part number you want to use (020, 030, 040...230, 240, 250).

 

I also like to keep an empty/blank model+icon around, so that if I have a weapon model that is a complete model, it only has to be made up of 1 part instead of 3. I do the same with 3-part shields.

[MerricksDad]

I did find that 019 opens anything from color 1 to 9. No in betweens were needed. I'll have to poke around with zeros again.

 

I was also wondering if single pixel icons can be used in place of larger blanking icons? Any clue?

[henesua]

I am interested in seeing some experiments with 0 parts, but given my experience with 0 parts messing things up I wonder how Amethyst Dragon makes it work.

[MerricksDad]

"but given my experience with 0 parts messing things up"

 

How do you mean messing things up?

[The Amethyst Dragon]

I did find that 019 opens anything from color 1 to 9. No in betweens were needed. I'll have to poke around with zeros again.

 

I was also wondering if single pixel icons can be used in place of larger blanking icons? Any clue?

 

I've used 2x2 icons as placeholders while taking toolset screenshots (for creating the inventory icons for Project Reforged).  They ended up showing as messed up rectangles of spots and lines, but still worked for my screen grabbing purpose. I did not try to use them in-game.

 

I am interested in seeing some experiments with 0 parts, but given my experience with 0 parts messing things up I wonder how Amethyst Dragon makes it work.

 

I use the 0 "color" (010, 020, 030...) for various weapons and shields, but not the 0 "part number" (000, 001, 002...).  I haven't run out of space in the higher part number ranges yet, so I haven't yet tested if the 0 "part number" functions or not.

 

When I started Project Reforged, I decided to add color 0 for my PW (rusted) since I was already going to be making new models and icons.  I had to make a bunch of empty "dummy" parts in color 0 so that I could still make use of the extra parts in the CEP.  Without a color 0 option for those extra weapons, none of them would show up in the toolset when making new items.

[MerricksDad]

gaw, after hours of poking around looking for actually GOOD textures for pines, I just can't find anything free. I may have to take a day and break out the lights and cameras.

 

Anybody know of any free foliage resources that don't suck, actually look like real pine foliage, and either have a very large texture to work with, or the alpha layer already done up?

[rjshae]

Not sure what scale you're looking for. Have you looked through the plant textures on http://opengameart.org/textures/all ?

[Lord Sullivan]

Maybe this would do?

 

http://andyvioustv.h.../pinebranch.jpg

 

Not texture ready, but you can work it out.

[MerricksDad]

Yeah, but thank you for posting that for folks again.

 

I think what I will do is go ahead and make another 100 or so foliage textures so people can use them. I have a lot of species around here and a city yard waste dump with 100's of species parts that wind up there. This should be fun, and it gets me out of the house for a bit.

 

Edit:

 

Which reminds me, I took a bunch of pictures of hemlock, as well as sandstone and limestone outcrops. And some mucky stream bottom with lots of rocks in it, all kinda green, but the water is mostly clear.

[MerricksDad]

Too much fun

 

[rjshae]

I guess you've probably already checked the Wikipedia Commons Category:Pinus as well then. Not really a texture site, but I've found it useful.

[henesua]

have you searched imageafter ?

 

these aren't great but worth a look.

 

I have a bunch of reference photos somewhere, mostly bark for the pines, but i might have needles.

[MerricksDad]

Making some progress

 

 

not my best work, but I think they'll work in game nicely for some of those "Skyrim Trees". Now I need to get some larger branches for firs, pines and spruces, as well as some dead branch variety.

[MerricksDad]

ok, so I am thinking I need to split deciduous trees and conifers into two separate builder scripts. All the stuff that conifers can do that the others can't needs an entire new panel of options. Either that or I really need to go back and review growth patterns.

[Rolo Kipp]

<turning all...>

 

That would have the added benefit of allowing deciduous trees to be responsive to season :-)

 

<...red>

[MerricksDad]

Yeah, I had already included some seasonal functions, but just hadn't gotten around to adding the leaf variations too. I'd done a 12 season model with an early, mid and late variety of each of the basic 4 seasons. When I got the species library worked on a bit more I was going to include in each entry when each tree blooms or sets fruit. It seems kinda over loaded for something for NWN, but it could really be used for just about any game, or even other purposes.

 

I was also thinking to encode some of my leaf shapes to internal builders, instead of packing this with a gmax scene. That way it could draw the shapes directly from the code without having to keep using the same parts libraries.

 

Edit:

Not sure how I would do that with the leaf textures...

[3RavensMore]

The blossoms and set fruit options would really work for setting the season, plus it has the added benefit of giving players something to forage for food--for those of us that love the added dimension of foraging, food, hunger, and thirst in their worlds.     

[MerricksDad]

I certainly like foraging In addition to fruit, I know a lot of trees, especially the conifers, have a huge texture variation between new growth and old growth. Not just in bark, but also in foliage color and shape. I was trying to be exceptionally specific, but yet allow the user to make a lot of variation on some options. This may be too much to incorporate, but maybe not.

[MerricksDad]

Making progress with meristem variants. Just need to tweak the orientation of the first node placed on the last node parent and we're good to do pines.

 

  

 

[MerricksDad]

All the above leaf textures are 256px images. I was thinking that if I make them somehow uniform in other ways, they may be more useful. One main thing I was thinking of doing was making the textures in such a way that the branch stem is at the exact same position on every texture square, and the facing then would be the same on every texture. That way, a user could simply texture replace any plane of foliage in a file with another without having to redo tverts.

 

Some quality will certainly be lost, but I have some tricks I can use to make that less noticeable. I'd like to keep the files in the 256 range. I think for generic foliage, 512 is just too much of a waste. Anything smaller is just too low quality. What do you guys feel about texture qualities? Should I simply do a 512 max size and pack it as dds?

 

The way I've done my bark and wood textures (and even rocks), is that the topmost portion of the texture is meant to be higher in Z position than those that are lower. This keeps the lightning direction uniform (as well as any gravity-based or overhead light artifacts on the image). I wrap a lot of my stuff in sphere, cylinder, or planar methods, so this works good for me. With tree foliage, I'd probably make stems on the bottom and outer foliage on the top. In this way I could also put smaller plant foliage into a mixed file with foliage tiles you might expect to find in the same region.

 

One of my biggest reasons for thinking of textures as squares instead of triangles is because of the research I did this week looking for the best way to mimic foliage from the smallest level (and producing the highest quality model). Most of what I found that looked good was all squares, with or without a bend in the middle of the texture plane. All those that used triangles or other shapes could have benefited from using squares, or otherwise the shape was created from an original square and then given more polys to bend (like with larger fir branches).

 

So what do you think? What do you use? And do you have tricks and tips for foliage?

[Rolo Kipp]

<totally...>

 

I like the idea of uniform placement. This would not only be convenient for text-editing mdls, but could also lend itself to procedural mix-n-match.

 

On the texture size, I'm kind of itching for an atlas at 512; but I understand (I think) why that's not a good fit for trees. Bear with me for a bit, just to put my thoughts down.

First impulse was make a 2x2 atlas of the seasonal/growth variation - bare, spring, summer, fall. But, really, you wouldn't normally be mixing seasonal variations in a single mod at the same time so any benefits of a atlas are largely wasted.

Second was a per-species atlas with trunk, foliage, flower, fruit. But again some of that is wasted "bandwidth" in that fruits and flowers wouldn't overlap so much. The bigger problem would be the trunk tex is tiled and the rest are decal. So the trunk *should* be single regardless.

Third iteration (after some expensive refreshment and an old man nap) is the trunk single and young foliage, old foliage, flower, fruit atlas would be pretty cool.

I *do* like my atlases ;-)

 

For size, a 512 DDS would give you the pieces your looking for at 256 and the option for the engine of LoD.

 

And square is good.

Though 512x256 wide rectangle for trunk might be better :-) Circumference = 3.1415* height, you know :-) <what?>

Edit: Er, girth = something wider than... <*face-wing*>

Oh, shut up, Bird. Let me drink my coffee... <heh>

 

<...square>

[MerricksDad]

<totally...>

 

I like the idea of uniform placement. This would not only be convenient for text-editing mdls, but could also lend itself to procedural mix-n-match.

 

On the texture size, I'm kind of itching for an atlas at 512; but I understand (I think) why that's not a good fit for trees. Bear with me for a bit, just to put my thoughts down.

First impulse was make a 2x2 atlas of the seasonal/growth variation - bare, spring, summer, fall. But, really, you wouldn't normally be mixing seasonal variations in a single mod at the same time so any benefits of a atlas are largely wasted.

Second was a per-species atlas with trunk, foliage, flower, fruit. But again some of that is wasted "bandwidth" in that fruits and flowers wouldn't overlap so much. The bigger problem would be the trunk tex is tiled and the rest are decal. So the trunk *should* be single regardless.

Third iteration (after some expensive refreshment and an old man nap) is the trunk single and young foliage, old foliage, flower, fruit atlas would be pretty cool.

I *do* like my atlases ;-)

 

For size, a 512 DDS would give you the pieces your looking for at 256 and the option for the engine of LoD.

 

And square is good.

Though 512x256 wide rectangle for trunk might be better :-) Circumference = 3.1415* height, you know :-) <what?>

Edit: Er, girth = something wider than... <*face-wing*>

Oh, shut up, Bird. Let me drink my coffee... <heh>

 

<...square>

 

about 2x2 atlas w/seasonal: my thoughts exactly

 

So what I had originally planned was a 4 foliage variation pack (upper left), with the right one-quarter of the texture set up for 5 sections of trunk/branch bark, 3 distinct variations and 2 mixer sections. Then across the 1/4 of the bottom, I was going to put specifics and decals. With this setup, any foliage set could easily be modified, or an easy-switch variety for it could be made. Most of the texture would be used on any model created from that texture. Alternately, if somebody would prefer to use triangles, the texture could be broken into 6 branch alternatives and possibly more room for 4 twigs, as shown in the second image. You could also divide any of the smaller decal area into triangles rather than squares. Either of these setups could easily do an entire species of tree, and without too much effort, could be modified to fit either another species, or to change the visual style, without also having to modify the model in any way.

 

  

 

about "Though 512x256 wide rectangle for trunk might be better":

 

I was thinking this also where the lower trunk texture would be a square, the mid trunk (or younger tree) would be a 1x2 rectangle, and anything younger could either be another rectangle or square at lower texture quality, or be a subtexture/decal on a larger plate.