How does one create custom trees?

[Abs]

As per the title. Thanks in advance. :)

Abs

[Beton]

Well...

i did not understand how the arma2 trees work yet. But you can take a look at the mlods from arma 1 as a first step to see how it is done. In my opinion arma 1 plants have the advantage of giving more fps compared to the new ones...
So if anybody could give an explanation on arma2 plants and textures and how to work with them i would be interested too...

[Bushlurker]

There a trees tutorial for Arma1 HERE (http://forums.bistudio.com/showthread.php?t=70790&highlight=trees)... Looks tricky... Good Luck!!


B

[DaSquade]

Personally i think making good looking trees is a very hard thing. Hence why BIS wrote their own custom program for that.

Looking at some Arma1 trees would be a good thing.
That tutorial above is indeed a very good thing and i don't think they come any better.

Just make sure you have a good balanced lod models. We all know have ungly the transitions are (= were? haven't played since a few months).

You might want to search some pro-tools forums. Maybe there are some script-like stuff around to make random leaves positioning around trunks. Could save you a lot of brainfarts.

[Abs]

Thanks a lot for the tutorial, guys.

Does anyone know if Mikebart ever ended up releasing part 2?

Abs

[Beton]

Maybe you can drop him a pm, he is still active in the forums.

[mikebart]

hey ABS, i will get to part 2 eventually which will explain how i did the lod's, i've actually started rebuilding the Elm from scratch, i felt there were a few things that could be improved in the workflow aswell as testing out some new ideas, feel free to pm me about anything.

I think the main reason for Arma1 trees being more efficient than Arma2 is that the arma2 trees have a second UV channel with a multiplied lightmap for extra shadow and colour variation, having a second UV channel at least doubles the vert count of a tree model.

[Synide]

having a second UV channel at least doubles the vert count of a tree model.

mmm, having more uv channels doesn't necessarily mean more verts. i guess it could if they doing some whizzy stuff with sm4 & gshaders but i don't think that's catered for in A2 is it?

multiple uv sets does imply more texels and consequently more shader work being done... well in comparison to A1 i'd surmise. also, by and large A2 trees have more poly's than their predecessors so that can add to the equation.

ya often find that it's usually a case of a whole bunch of little nuances that effect fps and it's very difficult to alter one thing without effecting something else... synergy is difficult in gaming engines.

one technique is too move to poly-planes in your own trees quicker than the BIS A2 trees do, but then you'll lose some of the qualities that goes with that. A2 trees tend to have 1-4 lods of lotsa-polies before going to simple planes. i think you could gain a few frames by just having 1 & 2 detailed and 3, 4 & 5 as planes or maybe leave a few detailing polies coupled with larger planes.
but, it's always dependant on what look you are willing to trade-off on I'd guess.

[mikebart]

yeah, I hear a lot of things about game engines, I usually assume that one thing goes for another and often get it wrong :)
Either way, lightmaps on second UV's are known to be expensive and dropping them from the material would probably speed things up.

I think we could be doing a lot more with the vertex normals on the higher lods, possibly as an alternative to adding a second UV set/lightmap.
Its just something ive had some experience with before and would like to apply to Arma vegetation.
Its a good, cheap way to get vegetation shading nicely with no extra cost, because you're just using something thats already there to get the desired effect.

the pics below show a bush that's made up of several clusters of foliage, each cluster is spherical in shape with the vertex normals projected out from the center, giving the foliage more of a volumetric appearance.

http://img9.imageshack.us/img9/7109/vertnormproj02.th.jpg (http://img9.imageshack.us/i/vertnormproj02.jpg/) http://img9.imageshack.us/img9/9854/vertnormproj01.th.jpg (http://img9.imageshack.us/i/vertnormproj01.jpg/)

I picked up the .mel script for Maya off a guy called joojaa over at Highend3d.com, here it is:


global proc jooProjectNormalOutForm(vector $center,string $points[]){
for ($item in $points){
float $pos[];
vector $dir;
//would need small tweak to support vertex faces
$pos=`pointPosition -world $item`;
$dir=unit(<<$pos[0],$pos[1],$pos[2]>>-$center);
polyNormalPerVertex -xyz ($dir.x) ($dir.y) ($dir.z) $item;
}
}

// run for all selected vertices facing away form world ceneter
// no more then rudimentary chek of correctness so be carefull
// what you choose. So only choose vertexes

jooProjectNormalOutForm(<<0,0,0>>,`ls -sl-fl`)

Just run place the proc into file named jooProjectNormalOutForm.mel in your user scripts directory and then put the jooProjectNormalOutForm(<<0,0,0>>,`ls -sl-fl -type float3 `) into your shelf as a button. (mmb drag teh text there form command editor) Restart Maya done. Select some vertices and hit the button.

Modify center to match what you need.



I've been meaning to try and get this going for 3dsmax, i just havent picked up my trees for a while, im not much of a scripter either so I'd rely on someone else to write it for me, I've had a few max scripters I know have a go at it, and they tell me its impossible/very difficult to do in max for some reason, maybe this is something easily done in Modo Synide?

[Synide]

...maybe this is something easily done in Modo Synide?

mmm, possibly, maybe a locator at the centre of the mesh with a orient constraint attached driving the normalmap bake would do it... possibly, or something similar, dunno.
and if i couldn't get modo to do what i wanted and had the inclination the other gauranteed method would be to just hack up a quick application to alter the normals (to anything you desire) in the appropriate LoDs of the p3dm.
there might be even a o2script command that may let you alter normals, dunno, haven't looked.

it does look better, but does it act the same over in buldozer/a2?

you should give her a go, and go right through to binarizing the model into a LODO/ODOL as you can never be certain, binarize might 'play with' any normals you might've set manually, but ya won't find out till ya try it.

the upshot is as your probably well aware, if it looks sufficient and has less poly's and reduced drawcalls and/or shader work on less texels then that's all a bonus. seems a little awkward though that if one got some sorta noticeable increase in vege perf and it looked reasonable to the eye it begs the question why haven't the BIS'ites implemented a heavy & light set of vege shaders. maybe other prohibitive rendering issues in certain circumstances. maybe they have and it's just not well documented enough.
again, you're probably well aware, this is how rv modding goes... you tweak, alter, punch & kick the thing till it sorta does what you want and if it doesn't break any of the other parts then you're all good.

[T_D]

...
there might be even a o2script command that may let you alter normals, dunno, haven't looked.
...
There isn't, O² just allows you to choose a normal calculation method for each vertex.

[mikebart]

you should give her a go, and go right through to binarizing the model into a LODO/ODOL as you can never be certain, binarize might 'play with' any normals you might've set manually, but ya won't find out till ya try it.

the upshot is as your probably well aware, if it looks sufficient and has less poly's and reduced drawcalls and/or shader work on less texels then that's all a bonus. seems a little awkward though that if one got some sorta noticeable increase in vege perf and it looked reasonable to the eye it begs the question why haven't the BIS'ites implemented a heavy & light set of vege shaders. maybe other prohibitive rendering issues in certain circumstances. maybe they have and it's just not well documented enough.


It has crossed my mind that BIS are aware of this technique, its something more commonly found in sprite sheet impostors and dynamic impostors of vegetation, which is something we've never really seen in a BIS engine as far as im aware. Some trees in Arma2 do look like they could be projecting vert normals from a point, but I know they're lightmapped so that would defeat the purpose, i think.

Well, I gave it a bit of a go, i couldn't get the .obj to export from maya too well, the vert normals were good but the UV's were blank when i imported a sample into O2. When i export from maya and into max, the vert normals reset themselves.
ill keep trying though, thanks for the advice, any more ideas would be very welcome.

[DaSquade]

Interesting approche, something i hope you work out more and share.

As for your blank UV's, if not mistaken .obj don't support multiple UV channels/maps. Forgot if that is the file itself or if O2 can't understand that 'code' when importing.
* You might want to 'save as .obj' instead of 'export as .obj' if maya allows this. Thanks to a hint of Panda, i noticed the save as is far better then export. At least that fixed some random missing faces i encountered in earlier modo models i made.
* If that fails, you might want to export/save the model with only 1 UV map at the time, altough i think i had imported multiple UVs in 1 model in the past (maybe something else then multiple UV of the same object, if you understand).
* If that fails, you might want to try .fbx export/save if maya has that. It should be a better export supported file anyway (better then .obj/.3ds) if not mistaken. Since the arma community toolset (02) doesn't support .fbx import sadly, you might be forced to contact Synide or me to import that file.

Anyway, good luck and i hope you keep us updated. Imho vegitation is one of the main performence bottlenecks in the engine although i thought BIS fixed already a lot of those issues.

[mikebart]

thanks for the suggestions, I had a good crack at it last night and today but i havent had much luck yet, i tried what you said DaSquade, all this exporting and importing from different programs is driving me nuts, looks like maya 2010 has dropped its .obj exporter for .fbx, you can switch it on in the plugin manager but it doesnt export with any parameters or anything, i dont need to export multiple UV's for this, but with .obj i cant even export a single UV, I also tried to copy the UV's from a .fbx import in modo, but no luck there, might be due to my inexperience with the program, I can definitly see modo being great for creating vegetation with the replicators, had some good fun with them :).

i've uploaded a few samples to the internets for if anyone wants to have a play around with them, you'll notice strait away if you import the 'EnglishElm_maya.obj' into modo that the vert normals are projecting from a center but it has no UV information, when I import the same file into 3dsmax the vert normals reset to default and no UVs too.

VertProjOut_samples.rar (http://www.esnips.com/doc/eae619b5-ec41-40bc-a837-f183bdb37432/VertProjOut_samples)

[mikebart]

Well, I managed to get the vertex normals and UV's working in modo by, exporting a .fbx from 3dsmax, then exporting that as a .obj from modo, then importing it to maya and running the project vert normals out script, and then finally importing it back into modo.

If i export it to .lwo from modo, could I get one of you guys to import to lightwave, see if the vert normals stay intact and then export to .p3d?, btw, any intention to make a modo .p3d exporter synide?

[Synide]

...any intention to make a modo .p3d exporter synide?

it's in the works... you can use these (ftp://203.97.251.53/p3dm2lwo_lwo2p3dm.7z) (56 Mbytes, not 24/7) 'old' standalone hacks to go lwo<->p3dm instead.

ps. can't remember if i'm trashing the normals when going from .lwo into p3dm in that prog. will have a look tomorrow and let you know.
had a quick look at code. the lwo2p3dm.exe is writing out whatever normals values it finds in the .lwo to the p3dm as is, so 'should' be sufficient.

[mikebart]

great!, thanks, ill check it out tonight and let you know how i get on with the vert normals, good to know about the modo exporter

[mikebart]

not much luck with the importer synide, although i dont think its any fault of yours, i tried converting a few primitives, and the vert normals came through fine in O2, so im guessing something strange is going on with my mesh, you'll see in the pic below that all the vert normals are projecting out along x and y.

http://img684.imageshack.us/img684/4569/o2nonormals.th.jpg (http://img684.imageshack.us/i/o2nonormals.jpg/) http://img203.imageshack.us/img203/7814/o2normals.th.jpg (http://img203.imageshack.us/i/o2normals.jpg/)

this is actually whats happening to the vertex normals once imported (.obj) into modo from maya after maya's done all its magic, it looks like one axis on each vert normal is being individually rotated 90, giving it a swirly appearance, it took me a while to realize that something was wrong.

http://img121.imageshack.us/img121/7631/modonormals01.th.jpg (http://img121.imageshack.us/i/modonormals01.jpg/)

heres the .lxo file which ive been exporting to .lwo from incase you want to have a look: EnglishElm_VertProjOut2.lxo (http://www.esnips.com/doc/8335fa9e-3e7f-412f-ba77-572dc67ba141/EnglishElm_VertProjOut2)

Im freezing all transforms before export, im not sure what else i could be doing, i've literally only been using modo a couple of days so would be good if someone more experienced with modo could have a look at it.

[Synide]

hmmm... you have a number of meshes in that .lxo file.

The one you should be looking at is under the 'item group' called 'EnglishElm_maya2' and seems to be exhibiting the normals you have worked up over in maya as you wanted.

Additionally, there was an error in that lwo2p3dm.exe in converting the normals which I just fixed it for you here (ftp://203.97.251.53/lwo2p3dm.7z) (lwo2p3dm.7z, 28 Kbytes, not 24/7).

I've confirmed manually the normals in modo exported to the .lwo appear correct and the tool is now converting the normals correctly over into the p3dm. You should only have 1 vertex normal map (if you have one at all) defined for the given mesh in modo though.

Even so, when I reconvert the mesh in your .lxo using the revised tool both O2 & Buldozer don't appear to 'like' the normals present in the same manner as maya & modo.

I dunno if you'll get very far with this... anyhoo.

PS.
A bit of background info.
In O2 although the application allows you to make a 'doubled-sided' polygon, say a quad with verts 0,1,2 & 3. When you come to binarize this p3dm binarize splits the 2 faces giving 8 verts.
In the process of doing this it may do some averaging of your normals producing some new value.
Possibly you may get around this by previously in maya creating the individually seperate sides of your 'doubled-sided' poly's so they are already distinct faces prior to running your script to calculate this 'fluffy' normals. then try going over to modo, then to O2.

I did try this with your mesh in modo, but when I split all the verts the 2nd set of verts created for the opposing faces seemed to go awry, however I could'a been looking at the vert normals in a the incorrect 'winding'.

Also, in your 'EnglishElm_maya2' mesh I noted you had some n-gons. You'll have to triangulate or quadulosulate (new word i just made up) them before running them through lwo2p3dm.

good luck.

oh, btw... I had a look at your previous .obj's that you had produced and were wondering where the uv's had gone... well, they hadn't gone... it's just they aren't in the .obj files at all... so, probably an issue with your exporting of them from whatever app that happened to be.

[mikebart]

Additionally, there was an error in that lwo2p3dm.exe in converting the normals which I just fixed it for you here (ftp://203.97.251.53/lwo2p3dm.7z) (lwo2p3dm.7z, 28 Kbytes, not 24/7).

I've confirmed manually the normals in modo exported to the .lwo appear correct and the tool is now converting the normals correctly over into the p3dm. You should only have 1 vertex normal map (if you have one at all) defined for the given mesh in modo though.


cheers for doing that Synide, i also get the way modo handles its vertex channels now after watching your tutorial.



Even so, when I reconvert the mesh in your .lxo using the revised tool both O2 & Buldozer don't appear to 'like' the normals present in the same manner as maya & modo.

I dunno if you'll get very far with this... anyhoo.


So we can pretty much confirm that the problem is happening somewhere between modo and O2.
I managed to get the vertex normals into modo ok. When i froze transforms in maya after running the Project Vertnormals Out script, i didnt have a freeze normals tickbox ticked in the dialogue in maya, I thought this would fix everything but they still aren't coming through in O2 properly (still winding) heres the updated .lxo if you're interested in having a look: EnglishElm_VertProjOut_FixedVertNormals.zip (http://www.esnips.com/doc/fc506382-dbeb-4ab9-a66c-73b1d962b511/EnglishElm_VertProjOut_FixedVertNormals)




PS.
A bit of background info.
In O2 although the application allows you to make a 'doubled-sided' polygon, say a quad with verts 0,1,2 & 3. When you come to binarize this p3dm binarize splits the 2 faces giving 8 verts.
In the process of doing this it may do some averaging of your normals producing some new value.
Possibly you may get around this by previously in maya creating the individually seperate sides of your 'doubled-sided' poly's so they are already distinct faces prior to running your script to calculate this 'fluffy' normals. then try going over to modo, then to O2.

I did try this with your mesh in modo, but when I split all the verts the 2nd set of verts created for the opposing faces seemed to go awry, however I could'a been looking at the vert normals in a the incorrect 'winding'.



ok thanks, thats really helpful to know, im working on a new test version of the tree where ill try what you've suggested with the distinct faces for polys.



Also, in your 'EnglishElm_maya2' mesh I noted you had some n-gons. You'll have to triangulate or quadulosulate (new word i just made up) them before running them through lwo2p3dm.

good luck.


hmm, i might have sent you the wrong one, or opened it while I had other scenes open and then saved it in modo, (still getting used to modo scene management)

thanks again for all the help with this, im not getting my hopes too high for this working now, but ill try to explore every avenue we can come up with till i hit a dead end, at least we'll know what doesnt work eh.

---------- Post added at 10:39 AM ---------- Previous post was at 10:08 AM ----------

I just found out that since maya2008, theres been a function called 'transfer attributes', you can find it in 'mesh/transfer attributes'.
Basically you can copy attributes from one mesh to another, for example vertex position and vertex normals, the numbers of the vertexes dont even have to match because it uses a raycast method, similar to how a normal map is baked from high to low poy geo.
So its perfect for projecting vertex normals not only from a point but from any shape, forget about the 'vertex Normal Project Out' script if you have maya2008. I probably would have known about this earlier if I was a dedicated maya user, but i usually use 3dsmax;)

I've written a quick tutorial on how to use it for your vegetation;

1. start by creating a polysphere next to your foliage model.

http://img704.imageshack.us/img704/5755/transferattributes01.th.jpg (http://img704.imageshack.us/i/transferattributes01.jpg/)

2. select the foliage first then the sphere, making the sphere the primary selection.

3. Open in the file menu, mesh/transfer atrributes, have only vertex position on in the dialogue (refer to image below)

4. select only the sphere object and drag/translate it over the foliage object until it 'shrinkwraps' itself around the shape of the foliage as shown in the image below.

http://img704.imageshack.us/img704/3375/transferattributes04.th.jpg (http://img704.imageshack.us/i/transferattributes04.jpg/)

5. freeze all transformations, now select the sphere then the foliage, making the foliage the primary selection,

6. in the transfer atributes dialogue switch off vertex position and swith on vertex normal and the foliage takes on the vertex normals of the shrinkwrapped sphere object.

http://img203.imageshack.us/img203/2333/transferattributes05.th.jpg (http://img203.imageshack.us/i/transferattributes05.jpg/)

[mikebart]

Just wanted to post about another idea im playing around with;
adding variation in foliage density by having duplicate UVs side by side but with 2 different levels of density on the texture maps.

http://img46.imageshack.us/img46/7165/uvsdiffuse.th.jpg (http://img46.imageshack.us/i/uvsdiffuse.jpg/)

http://img46.imageshack.us/img46/1499/lightandfull.th.jpg (http://img46.imageshack.us/i/lightandfull.jpg/)

so you get parts of the tree which are dense with leaves and other parts that are kind of see through, you could also change the textures so that there are no leaves on one side and a few leaves on the other side, use it to add a bit of extra colour variation etc...

http://img695.imageshack.us/img695/213/lowpolytree01.th.jpg (http://img695.imageshack.us/i/lowpolytree01.jpg/)

[Synide]

So we can pretty much confirm that the problem is happening somewhere between modo and O2.

Nah, not 'tween modo & O2... just O2... it's playing with the normals.

The normals in the .lxo and the normals in .lwo are exactly the same.
The normals in the .lwo and the .p3d are exactly the same.

As soon as you open the p3dm.p3d in O2 it calculates it's own normals for each vert. and upon saving the model the 'custom' vert normals are overwritten. The O2 calculated normals are significantly different to the 'custom' values in the p3dm.p3d prior to opening in O2.

There are three point flags one can set in O2 for a given point relating to normals. One of these is 'lock' the normal for the point. I have altered the lwo2p3dm.exe (http://203.97.251.53/lwo2p3dm.7z) (28 Kbytes, not 24/7) to set this flag on all points when converting from the .lwo to the p3dm.p3d.

With this flag already set for each point upon initially opening the p3dm.p3d in O2 you'll note that the normals are all coloured 'pink' instead of blue. This indicates they are 'locked'.
However, O2 is still visually representing them in the O2 viewport incorrectly. And, additionally if one immediately saves the model without making any alterations whatsoever the normals for each point are almost exactly the same as prior to opening the file but still they are ever-so-slightly numerically different.
So, even with the 'lock' normals flag set on each point O2 is still ignoring this and altering your custom per-point normals.

With SA's max plugin I'm not sure if he has completely divorced any requirement for opening a p3dm.p3d created from max in O2. Perhaps he has you'll have to ask him. If so, and you no longer have to go near O2 then perhaps the exported from max p3dm might retain any custom normals you may set and hopefully binarize.exe when converting to lodo format won't play with them either.
I'm hoping to eventually achieve the same senario with a modo plugin also, but it takes time when your not a guru c++ programmer and ya have little spare time.

[mikebart]

The big problem im having with 3ds max and vertex normals is that i just cant import them properly, they actually appear quite similar to how we had them originally in O2 with them pointing along the x and y axis, there's an edit normals modifier in max but it really doesn't do a lot apart from averaging or making them all face the same way, which is pretty useless for what we're trying to do here, max just isnt very friendly towards vertex normals.

So can you confirm with me that the winding vert normals are happening in O2 because O2's getting some of its vert normal rotation axis mixed up?, Do you think it might be possible to somehow 'trick' O2 into importing the vert normals with the correct orientation by adjusting those axis before importing?. It sounds a bit of a dodgy thing to do, probably not a good idea.

[Synide]

So can you confirm with me that the winding vert normals are happening in O2 because O2's getting some of its vert normal rotation axis mixed up?

Yes.


Do you think it might be possible to somehow 'trick' O2 into importing the vert normals with the correct orientation by adjusting those axis before importing?

No.

Although I haven't tried it the only last alternative would be to bypass O2 and take a p3dm.p3d and just run it through binarize.exe. If I find time I'll give that a try for you. But as I mentioned before. Binarize may well also 'play' with the custom normals during converting the p3dm to a lodo.
Also, unless one creates a third party plugin for one of the commercial 3D apps capable of emitting a 'well-formed' can 'complete' p3dm.p3d it becomes an onerous chore constructing a p3dm.p3d by hand that the user does not need to bother even opening in O2 but can just use as is with BinPBO/binarize.

[PuFu]

to get this: the vert normals are getting all weird in o2, although modo has them correctly. Are those normals screwed on save, or right from the start (also viewed in viewport?)

sorry to get in the conversation, but it seems for me that the vert normals are getting changed mainly because of the working plane (different depending on application)
In that case (i can only make a supposition here due to not knowing exactly how the lwo2p3d works) it might be similar to some issues i had importing obj files from max in o2, without changing the working plane on export.

[mikebart]

Dont be sorry, the more the merrier :), the normals are getting screwed when loaded into O2, yeah it seams the working plane is ok on all other transforms but the vertex normals.

I can import an .obj from maya with working projected normals into O2, but its without UVs, and i havent had any luck copying from 1 model to another.
If you're interested in having a look, check out the link i posted a few pages back, it has some samples in different formats exported from different programs.

[Synide]

I can import an .obj from maya with working projected normals into O2, but its without UVs, and i havent had any luck copying from 1 model to another.

hmmm, which .obj was that? must'a missed that one...

[PuFu]

I can import an .obj from maya with working projected normals into O2, but its without UVs, and i havent had any luck copying from 1 model to another.
If you're interested in having a look, check out the link i posted a few pages back, it has some samples in different formats exported from different programs.
I'll have a quick look later on. 3dmax2010 has a list of editable presets for exportin obj, never had an issue with missing UVs.
http://i239.photobucket.com/albums/ff105/KH_PuFu/obj_export.png

talking about this one, yes?


i've uploaded a few samples to the internets for if anyone wants to have a play around with them, you'll notice strait away if you import the 'EnglishElm_maya.obj' into modo that the vert normals are projecting from a center but it has no UV information, when I import the same file into 3dsmax the vert normals reset to default and no UVs too.

VertProjOut_samples.rar (http://www.esnips.com/doc/eae619b5-ec41-40bc-a837-f183bdb37432/VertProjOut_samples)

[mikebart]

hmmm, which .obj was that? must'a missed that one...

Actually it might not have gotten in there, sorry i've lost track of all the exports i've done, it all got a bit muddled up.



talking about this one, yes?

yep thats the one I meant, but never mind about checking those out.

I actually managed to get it imported into O2 from maya .obj, with vert normals and UVs working fine, I hope i didnt waste too much of your time with this Synide, Pufu or anyone else who looked into it, sometimes its the simplest things that elude me with this stuff, thanks for all the help guys.

heres how i managed to do it; exported from maya to .obj, made sure normals were ticked in the 'freeze transformations options', imported to O2, selected all verts, opened 'points, propertys' and locked the vert normals through there, otherwise they get unified on saving the .p3d or with any other adjustments aswell, e.g copy and paste, unifies vert normals if they're not locked, thanks for making me aware of that flag Synide.
I guess its not over yet till I binarize complete with other lods, I also need to see how well I can match the projected vert normal effect with the other visual lods.

one disadvantage is that due to the direction of the vertex normals I cant use the NormalMapSpecularThrough vertex shader, which uses noise in the alpha channel of the _NON normal map to fade foliage planes when they align adjacent to view, and fades the foliage when it hits the near clipping plane. So i have to use NormalMapSpecularThroughNoFade instead, which is ok i think because of how the foliage is rendering you dont really notice the "plane spikes" so much and It still fades between lods.

http://img96.imageshack.us/img96/6806/elmsmallcompare.th.jpg (http://img96.imageshack.us/i/elmsmallcompare.jpg/)
left: unified vertex normals,
right: Projected vertex normals with VertexShaderID="NormalMapSpecularThroughNoFade"

you can see here what happens when I use the fading shader.
http://img695.imageshack.us/img695/1430/elmsmallcompare2.th.jpg (http://img695.imageshack.us/i/elmsmallcompare2.jpg/)
left: unified vertex normals,
right: Projected vertex normals with VertexShaderID="NormalMapSpecularThrough"

http://img192.imageshack.us/img192/2939/elmsmallvisitor.th.jpg (http://img192.imageshack.us/i/elmsmallvisitor.jpg/)
I hope I can get the lods looking something like this off in the distance, you'll notice the foliage looks quite volumetric, and they also receive light dynamically.
Theres only one lod at 1360 points at the moment but its only a small tree, it has much better use of UV space and vert count than my previous attempt, so I feel a bit more comfortable about completing the tutorial now. Ill probably start the tutorial again from scratch, I plan on making another large version of the tree eventually too.

Here are 2 samples, one with unified vert normals and one with the projected ones.
Download elmSmall_samples (http://www.esnips.com/doc/158766ba-03cd-4f61-b269-3b2c2297b18a/ElmSmall_vertNormalProjOut_samples)

[Synide]

That's great news mikebart, well done. Best things come to those that persist and I'm whole heartedly pleased you proved my gut feeling wrong.
Can you post a link to your .obj, I'd like to dissect it and the importing of it into O2 at some point when time allows.
Just had a look at your .p3d, 1300 faces and looks good to me... again, well done.

[mikebart]

Can you post a link to your .obj, I'd like to dissect it and the importing of it into O2 at some point when time allows.

heres a new version of the .p3d with visual lods 1,2 and 3, it also includes the .obj exported from maya.

elmSmall_with_lods.zip (http://www.esnips.com/doc/3d96c96b-c494-4778-ab5c-ffa375c4e308/ElmSmall_with_lods)

Thanks again for all the help synide, but I got to say, we're not out of the woods yet! (excuse the pun)

I think theres going to be a fair bit of work to do on the lods to get them looking ok, Lod2 is playing up for some reason the textures flashing from light to dark as you move around it, probably something with the geo, ill check it out through the week.
And they're actually not fadeing between lods properly now that im using the "NormalMapSpecularThroughNoFade" shader, which could be the killer, you'll notice if you place the Elm_small_VertNormalsProjOut.p3d in visitor, run bulldozer theres some serious lod popping going on, although when you move towards or away quickly you'll occasionally see a lod fade in or out.

edit: fixed; was due to low object detail settings.

[quiet_man]

Thanks again for all the help synide, but I got to say, we're not out of the woods yet! (excuse the pun)

that's a good one :cc:

one question: Do you think the way you try to get the trees done is the one for the future?
Or are the BIS trees the future and they are only a bit ahead of "time" (= hardware)?

QuietMan

[mikebart]

I'd say the altered vertex normals for dynamic shading + lightmaps for ambient shadow and colour variation would be the way to go for the future.
I dont really know about BIS trees being a bit ahead of time, they're the nicest looking trees i've ever seen in a game, and that game has a 10 km veiw distance at a FPShooter level of detail, so yeah they do pretty well I think, obviously the guys making them know what they're doing, but sometimes in a production environment you simply dont get time to try out every idea that comes to mind, or maybe they did try projecting vert normals but dropped it for fading foliage planes. One negative about using the altered vertex normals means that the foliage planes will no longer fade properly when they become adjacent to the player or when they hit the near clipping plane, so thats the only loss i can really think of, everything else about them is a visual gain with no extra cost, and they still fade normally between lods.

from looking at some of the normal maps from the BIS trees, ive think they're either overlaying a normal map of a sphere over each peice of foliage or, each peice of foliage has projected vertex normals and they've rendered them to texture, so who knows...

left; mikes projected vertex normals, right; BIS vertex normals.
http://img641.imageshack.us/img641/267/bisnormals.th.jpg (http://img641.imageshack.us/i/bisnormals.jpg/)

but if it walks like a duck and it quacks like a duck, then maybe it is a duck. :cc:

im glad you appreciated my pun quiet man, for a while there i thought i'd killed the thread with it.

[BadBenson]

just wanted tell all 3ds max users who want to try this out that there is a script for max which lets u do the same kind of normal transfer.

here's the link: http://www.scriptspot.com/3ds-max/scripts/normal-thief

[mikebart]

just wanted tell all 3ds max users who want to try this out that there is a script for max which lets u do the same kind of normal transfer.

here's the link: http://www.scriptspot.com/3ds-max/scripts/normal-thief

have you tried it out? man, I've scoured script spot looking for something that does this for max. ill test it out later, thanks for this.

[Bad Benson]

i made a lil test using the script. seems to work.

left default (arma1 sample model) right custom normals
http://img193.imageshack.us/img193/6219/testnvg.jpg

[mikebart]

nice one, is that in bulldozer?, I didnt spend too much time with it, but I had a go with a 1000 vert peice of foliage and it took a very long time to process, but the results were the same, did you try importing to O2? my normals were unified in oxygen when i imported from .3ds, and O2 crashed when i imported as a .obj.

[Bad Benson]

yeah this is a buldozer shot. i exported as obj and i unchecked the optimization stuff cuz i didn't want anything changed. not sure if that did the trick cuz i'm not that familiar with all the theoretic stuff being discussed here. i checked after saving in o2 and the settings are still there. i think i made that lock normals stuff u described too.
btw in case u didn't know, u can use another script to make the sphere fit the shape of the tree crown (like u did on one of those maya screenshots) named retopo before running the normal script.

[trezza]

I'd be interested in creating an Australian tree set for arma2, the modeling looks difficult and complex, too many things in one place, I'm not good at difficult and complex but I'd be willing to go out with my camera to find native trees and snap some shots of the bark, a whole tree from a few different angles and also spend some time picking off leaves and twigs of a few branches until i have a flat branch which I could take a photo of against a flat surface all to help with the textures, most eucalyptus trees are quite tall with long trunks so you wouldn't need to worry too much about the detail of the leaves because they all grow at the top. Also the grass could be replaced, in the Australian bush I've found that the forest floor is mostly small ferns or bracken, the grass grows in tufts more often than a complete layer of grass like in chernarus.

If anyone with plant making experience is interested then PM me and tell me what is needed. I'd like to have a go with an authentic Aussie island for arma2!

[mikebart]

Sounds good trezza, I think it would be a good idea to make a new thread for this sort of thing and post up some photos, ill post up some of mine as well, call it the 'vegetation reference thread' or something :).
I loosely explained what I look for personally when taking photos of trees for modeling/textureing in this tutorial (http://www.armaholic.com/forums.php?m=posts&q=5197&n=last#bottom). But i'd recommend going through the BIS tree textures found in Arma1 and 2, just to get an idea of the sort of leaf density and shapes you should be looking for in photos. The thing with Gum trees though is that the leaves are always drooping downwards, so i think that should be an important thing to keep in mind while modeling them (something covered in that tutorial), and thats why it should be made from scratch i think, as none of the BIS trees would be suitable as a template.

Gum trees have been on my 'to do' list for quite a while now, just havent quite gotten around to it, but the projected vertex normals (explained a few pages back) would be ideal for this type of tree. So i'd be happy to help out with this.

[mikebart]

>>>>>>>Download tree[d] (http://www.frecle.net/index.php?show=treed.about)<<<<<<<


Hey again. I've been playing with tree[d] since my Max attempt turned out rather crappy, and it's a lot better than it seemed at first glance.

http://xs.to/image-B9FC_4BED75D8.jpg

http://xs.to/image-132A_4BED75D8.jpg

http://xs.to/image-ECA0_4BED75D8.jpg

Branches look a bit mechanical sometimes, but that's probably due to the settings used. The images above seem to me like they could be used on a polyplane right away. Only issues are that the lighting doesn't seem to be editable, the built-in RTT is limited to 512x512 for some reason, and you can't really do the normal/spec maps properly off of the above images.

It exports fine to OBJ and I was able to load it up in Max. After some fiddling with the alpha on the leaf textures it looks just like the tree in the program, however I can't seem to recreate the lighting. It also seems like you lose the random leaf color variation when exporting, as they're all mapped to a single texture. I'm not too experienced with Max, though, so all of that might be fixable, and then you could use your projection baking method to get polyplane textures.

It generates pretty good trunks and branches, too, so you might be able to use the exported mesh as a base for the ingame trunk model.

It's a pretty awesome little program and it's great they're giving it away even though it's apparently been worked on for close to ten years.

looks great!, thanks for sharing, the only problem with using the projection baking in max is that alpha channels don't get included in the render, so you end up with lots of planes for leaves, unless you use this method: http://www.bencloward.com/tutorials_normal_maps11.shtml
basically you manually setup all the lights for you're normal map and render from a camera.
its a bit of a pain but once you have all the lights setup properly then you can just save them as a .max and merge them into your scene when you need them.

Just to save you a bit of time, heres my setup: normalmap_lights.max (http://www.esnips.com/doc/4ab65331-4037-4a5b-85d0-3d058cdf8cc3/normalmap_lights)

and heres my lighting setup: diffusemap_lights.max (http://www.esnips.com/doc/08d1d0b9-3eb7-42dc-8eda-86d6f88418e2/diffusemap_lights) its pretty simple really but its enough i think for the render.

or you can use modo for you're baking, modo includes alphas in its projection bakes and its very easy to use, maya might work too, not sure though i havent tried.

about the random colour variation, im not sure of a quick way to do that in max, you could try adjusting vertex colours on randomly selected leaves, or applying a lightmap on a second UV. you might also find a script out there that does something like that.

[cctoide]

Thanks a lot for the scenes, I've managed to get a generated branch properly diffuse and normal mapped. Looks great.

Also, I found a couple other generators that look pretty good:

ngPlant (http://ngplant.sourceforge.net/) seems to be basically a fancy 3D L-system interface, it's slightly more flexible than tree[d] though the preview isn't as good. This might be good for generating smaller plants (e.g. fern leaves, weeds, etc.). You can have as many branches and sub-branches as you like, and more than one branch per level. Branches can also be triangles, quads or tubes. There aren't "leaves" per se, they're just branches with a different mesh and texture. Exports to OBJ. No restrictions on output that I can tell.

powerPlant (http://sourceforge.net/projects/pplant/) looks good but I haven't managed to get it running, the batch script it creates tries to run it via a command that doesn't exist, even though I have Java installed. Will check it out later, I guess.

[mikebart]

Hey guys, I just found some more information about vertex normals in regard to vegetation, for those of you that didnt fully understand what they're all about, someone has written a tutorial with some useful data explaining the purpose of vertex normals and how to manipulate them in 3dsmax/maya, theres also a link to "slideNormalTheif", which is pretty much the same as "normalTheif" the one BadBenson posted a link to previously in this thread, except its super fast :)

http://wiki.polycount.com/VertexNormal#What_Is_a_Vertex_Normal.3F

@cctoide, thanks for the links!