How does one create custom trees?

[abs 2]

As per the title. Thanks in advance. :)

Abs

[beton 2]

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 46]

There a trees tutorial for Arma1 HERE... Looks tricky... Good Luck!!

B

[DaSquade 0]

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 2]

Thanks a lot for the tutorial, guys.

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

Abs

[beton 2]

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

[mikebart 1]

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 0]

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 1]

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.

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 0]

...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 47]

...

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 1]

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.

Edited February 9, 2010 by mikebart

[DaSquade 0]

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 1]

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

[mikebart 1]

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 0]

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

it's in the works... you can use these (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.

Edited February 15, 2010 by Synide

[mikebart 1]

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 1]

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.

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.

heres the .lxo file which ive been exporting to .lwo from incase you want to have a look: EnglishElm_VertProjOut2.lxo

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.

Edited February 16, 2010 by mikebart
fixed broken link

[Synide 0]

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 (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.

Edited February 17, 2010 by Synide

[mikebart 1]

Additionally, there was an error in that lwo2p3dm.exe in converting the normals which I just fixed it for you here (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

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.

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.

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.

[mikebart 1]

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.

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...

[Synide 0]

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 (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.

Edited February 19, 2010 by Synide

[mikebart 1]

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 0]

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 4600]

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.