HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - McIndus

Pages: [1] 2
By Patrick McGuire - for Hero Engine with Omzy’s Shader

When using Omzy’s Terrain Shader, there are several things you must keep in mind:

The spec map is now not ideal, but on terrain I’ve found it to work better this way.

When generating spec maps, try to create black/white ranges that are balanced between the different textures for the zone.  This way, you can use more consistent opacity settings while painting terrain.

Layer 1 - or the bottom layer, is unaffected by the shader, so any layer that is placed directly on top of layer 1 will act as the HE default opacity blend. (This works especially well when you have a varying normal/diffuse UV combination.

Every Layer (besides layer 1) will only paint the texture that is ‘highest’ based on the opacity (or ‘strength’) slider level and the ‘shader spec’.

Creating the Proper Spec Maps: (MOST IMPORTANT STEP)
  • Create a ‘spec map’ - preferably from the texture’s ‘normal’ (or use current one)
  • Create a ‘heightmap’ - essentially where black is the lowest point and white the highest. (Can also be created from the normal, but I find that a custom B&W version of the diffuse texture can also work very well)
  • Place the ‘spec map’ as a layer above the ‘heightmap’
  • Make the ‘spec map’ layer an ‘overlay’ or ‘soft light’ layer
  • Adjust the levels of the layers to create a nicely balanced result and merge them.
  • Lower the overall brightness 30-40% due to HE’s crazy spec settings and due to ease of use for painting.
  • Add this new ‘shader spec’ to the alpha channel of your old ‘normal’ file
  • Save as DXT5 with Kaiser mips. (I also use 1.1 blurriness blending)

Painting the Textures:
  • Use one of the Custom Brushes to paint textures. (Or Perlin Noise)
  • Paint with about 60-75% of the opacity you truly wish first to paint the main ‘body’ of the texture - this gives a good base, and doesn’t create hard edges between textures. Remember to use the shift+ctrl ‘rotate’ feature to get varying randomness in the placement of the textures as you paint.
  • Then go 75-90% with a smaller brush and connect the main parts of the texture.
  • Crank up opacity to 100% and use a brush set very small (one or two vertices) to do bold centered detail work.
  • Drop the opacity to 40-50% to do the trim of the textures, but try to avoid tiling.
  • Drop the opacity to 20-40% and paint all round the edges for fine detail to finish off your transitions.

Other Notes:
Using large resolution normals: BE VERY SPARING
  • Use a normal that best accents the terrain and texture
  • Set it to as low as ¼ of the diffuse texture UV size (huge)
  • These normals tend to need a varying degree of ‘noise’ to keep the texture detail in tact
*** The spec on these normals will apply to the huge UV, but the shader will only apply the spec depth range to the diffuse UV.
**** Use these as infrequently as possible, as the filesize is 4x the original

Using inverted normals:
When creating snow, sand, and other textures you wish to ‘fill-in’ between crevices in the texture below (texture A), you can:
  • Invert the base texture’s (texture A) normal and spec.
  • Use this inverted normal (normal A_inv) paired in-engine with your fill-in diffuse (texture B)
  • Make sure the UV of your new [normal A_inv] matches the UV of [texture A]
  • Paint over texture A with texture B (paired in-engine with normal A_inv).


Art & Art Pipeline / Re: Dynamic Detail "Popping" Issue
« on: Jan 29, 18, 01:20:21 PM »
I'm not using stylesets... just a terrain scheme that's been applied to all of the areas.  Also didn't use the clone stamp to paint any details.  What do you mean about corrupt maps/area.dat files?  I doubt that would be the case, seeing as these are all very new/fresh areas - etc.  I'm also pretty sure I have no dyn errors in my console, but I'll double check.

Art & Art Pipeline / Dynamic Detail "Popping" Issue
« on: Jan 27, 18, 03:24:51 PM »
I am having some strange issues with Dynamic Details loading upon crossing area seams.
Here's a video with the entire process and my audio explanation of this issue:

I know that if I paint from one area into an area that i'm not currently -in-, that my details may vanish when I cross the area seam -- however, this is NOT the issue I'm running into.

Sarrene painted some billboard grass (Dynamic Details) in an area, and when I walk into that area with my character, the grass disappears like so:

Which is interesting because the grass originated from the area that i'm loading -into-.

I then painted billboard details myself and the details 'popped' back into existence immediately:

So I was wondering what was going on... was it me painting dynamic details or just effecting the heightmap?  I then reproduce this 'popping back' using other methods:

Painting a Texture:

Modifying Height:

This is an issue that I also see happening in Repop when you cross an area/zone line into the next, and doesn't seem to happen while crossing heightmap seams within the same area/zone.

Design & World Building / Re: Speed Tree Question
« on: Jun 07, 17, 02:14:03 PM »
For SpeedTree imports there are a couple of methods:

1.  Add each tree individually and clone/move to your hearts content. (Only good for an area with few trees, or when you need to drop in a 'special' tree asset that's unique to the area - this is heavy on drawcalls)
2.  Create a 'group' of trees in SpeedTree and export them in order to drop them in with less draw calls. (can also clone/move)
With ST's forest functionality, you can get some really great results.

For your Bushes and Grass, you really should be using the DynamicDetails portion of the Terrain Editor. 
This will allow you to use the 'painting' method you mention in your post.  For bushes, you might want to use the 'meshes' portion - and for grass, you should use the 'billboards' section in the Dynamic Details tab.  These meshes do not get physics, but the billboards will be effected by the environment wind.  This is to save on a whole bunch of physics math - especially since you don't want that much info to run server side.

Also remember that as you get more comfortable with HSL, you can create your own custom tools.

Hope that helps!

Also, how to properly duplicate (or clone) assets in Hero according to the wiki:
Code: [Select]
Duplicating assets
Duplicating (or "cloning") an object is simple. To do this:
Click on the object you want to duplicate.
Duplicate either with Ctrl+D, or by opening the Assets panel, selecting the GUID and choosing Clone instance in the Instances Menu.
The new (duplicated) object appears on top of the old one, and will be automatically selected.
Using the mouse wheel, cycle to the Select & Translate tool {{translate)) (or click on that tool in the Transform Toolbar)
Move the duplicated asset so it is no longer on top of the original asset

You can also create another Instance of the last Asset you added from the Library, with Ctrl+Q. This differs from cloning in that it will create the Instance from the Asset, which means things such as Rotation, Scale, DiffuseColor, and so on will not be set.
To place multiple of the same assets, select it with the Dynamic Place Tool, and then press Ctrl+D to drop duplicate versions wherever the mouse is.

Oh yeah! Also, to add diversity without having to go through the painstaking process of manually trying to 'randomize' the terrain assets - use this feature:

Off Topic / Re: Direct3D problem
« on: Mar 21, 17, 01:00:23 AM »
Yes, I am having a similar problem.

I used to run HeroBlade on a much older computer, but for some reason on my Intel(R) HD Graphics 520 I am having issues.

I tried what was suggested to no avail. Also, there are no issues from dxdiag.exe that I can see.

Try this: 

And then you should go here and download these drivers, which should fix any missing DLL issue:

Hi McIndus, thanks for trying to help !
Unfortunately I get an error trying to install this..

Make sure you run it as admin.  Whatever you install for DX9, make sure you run as admin.

I hope the link Jonathan sent you worked out for you, but in case it didn't, you can look in your Windows Update and search for any relevant DX9 updates.  I believe you may be missing D3D9.dll and other components that the web installer doesn't include for devs - but I do know that these exist as "optional installs" in your Windows Update.

Let us know if this helps!

You might want to try the dev link for dx9 runtimes... the web installer doesn't include everything.  (It states that it's missing certain key components in the description.)  This is what enables dx9 games that need d3d9.dll, etc. - check out this link.


I think you can also look through your optional windows updates for the files as well... not quite sure why windows makes this a pain in the arse.

Awesome!  Thanks for posting my tutorial!

I hope this helps people get started with world creation in the HeroCloud :)
Next up:  World Building, Terrain Textures, and more!

Omzy's Advanced Texture Shader
For use with HeroEngine

Hello fellow Dev's!
We at Odyssey of Ydris have been working hard creating our world these past few months, and in the process we have created a Texture Splatter shader for use with HeroEngine that revolutionizes the way texture layering is processed by the engine.  This shader is merely a few lines of code injected into an existing .fx shader file within your repo. 

You can read more about how to use custom shaders here:

I was working in our world when I became frustrated with the way opacity blending worked.  There were textures that faded into nothingness, and unless you became extremely creative with alpha layers, you couldn't really create realistic layering effects with your terrain textures.  I ran across this article (http://www.gamasutra.com/blogs/AndreyMishkinis/20130716/196339/Advanced_Terrain_Texture_Splatting.php) which explains the math and the process for creating more realistic layering, and directed it to Omzy, our owner/programmer/developer.  In response, he provided me with this shader, and we're sharing it with the community!

This custom shader replaces the normal opacity function on all layers except the bottom layer.

In order to create 'depth', you must use the alpha layer of the normal map (currently only for spec).  To do this, create a heightmap/bump map of your texture and blend it with your spec map, so that the image has pronounced highs/lows. (you can modify/tweak this later using levels, brightness, and contrast controls).  You must create a 'balance' between your spec and your heightmap so you don't completely sacrifice your spec.

I will be providing a more in-depth texture splatting tutorial using this shader at a later date.  Until then, this video pretty much sums up how this functions:

And now for the shader!


Find this code in heightmappermutations.fx locade in your "Render/shaders200a/game" folder:

    #if defined(DO_TEXTURE_ALPHA)
      fadevalue *= diffuseTexColor.a;

(Insert the code below here)

    diffuseTexColor.rgb *= In.VertexColor;

Code: [Select]

float4 normaltexture = tex2D(NormalSampler,In.TexCoord0.zw);
float heightval = normaltexture.w; //w is alpha, which contains spec = heightmap substitute
if (fadevalue > 0.2 && fadevalue < 0.6) { //transition width is 0.4
float fadenorm = (fadevalue - 0.2)/ 0.4;
float edgenorm = (fadevalue - 0.2)/ 0.0625; //edge blend value
if (fadenorm < (1-heightval)) {
if ( fadenorm > (1-heightval)*0.55) { //blend a few adjacent pixels
if ( fadevalue < 0.3) { //blend the edge down
fadevalue = (fadenorm - (1-heightval)*0.55) / ((1-heightval)*0.45) * edgenorm;
} else {
fadevalue = (fadenorm - (1-heightval)*0.55) / ((1-heightval)*0.45);
} else {
fadevalue = 0.0;
} else {
if ( fadevalue < 0.3) { //blend the edge down
fadevalue = edgenorm;
} else {
fadevalue = 1.0;
} else {
if (fadevalue < 0.2) {
fadevalue = 0.0;
} else {
fadevalue = 1.0;

Screenshots of how it's used in our game:

And a video flyby of our world in progress:

MCINDUS and Omzy

Odyssey of Ydris

Art & Art Pipeline / Re: Speedtree Questions
« on: Jul 10, 15, 01:33:11 PM »
     Okay, just so I can be clear, do the leaf billboards move independently of the branches?

This brings up an awesome point. 
Is there anywhere that lets us know what features from SpeedTree actually work in HE?

For example, lighting/color changes don't export, alpha scalar changes don't export (probably a per-pixel issue), parallax bumps aren't applying to textures, trans maps don't seem to apply, and Wind only functions on a very basic level, but the specifics as to what wind settings DO work are unknown.

Some extra info on the wiki would be helpful and prevent me and MANY other devs from wasting more time.  I've already spent about 30 hours on trial/error in SpeedTree trying to figure out WTF HE supports.

From my experience, unless the object has bones with physics applied, it won't move in the wind... and even then, weird stuff happens.

I can't get bushes I've made to blow in the wind.  I made them out of fronds, and when I select 'Fronds as Leaves", the wind settings don't export to HE.  (since leaves have no bones, I'm assuming... even when I manually create bones)

After a lot of trial and error, I found that by keeping the leaves as 'fronds' I could use a few settings that work well to make the wind for fronds 'act' more like leaves, even though they are still fronds.  Things look great in SpeedTree, but as soon as I import them using the compiler, the leaves 'stretch/contract' dramatically in game and look like crap instead of blowing in the wind.  This is totally unpredictable behavior at the moment, and would be really nice to find a fix, or at least to know specifically how HE handles SpeedTree wind.

I don't think wind actually applies to billboards at all.  Is there a workaround for this?

The diffuse maps in the engine store color information. The normal map, or bump plus spec, hold directional information about the normals of the surface. Hope that helps!

I know that diffuse store color and that normal maps are the 'bump' map + spec (by default in HE).  That is fundamental texturing, but what I'm asking is more involved and specific.  As it stands, you can also have an Alpha channel in your diffuse texture.  If a file is saved as DXT5 with an alpha channel for the terrain textures, the alpha 'masks', portions of your diffuse texture and they become transparent.  I'm asking if there is a way to alter this performance (through a shader perhaps) to have the Alpha channel of the diffuse be a parallax map for the texture instead.  Hero Materials lets you accomplish this task, but I see no such functionality for the terrain.

If you look into Hero Materials, you can save several different types of "texture maps" into the alpha channel of the diffuse - such as parallax/bump maps for your texture.  This can be used in combination with a 'normal' map (another 'type' of bump map which has it's own set of alpha settings for spec,) which gives excellent results.  I was hoping that someone might help direct me to the shader that controls this, or give me some other information pertinent to my questions.

Here is some more information on the topic, as how it relates to normal mapping and other game engines:

How are normal maps used then?

This depends on the game. Although normal maps have 4 channels available for use; Red, Green, Blue (X, Y, Z) and Alpha, some games tend to use just two of them; the Red and Green ('X' and 'Y') channels (the alpha channel often used as a mask or filter to blend or remove image sections). This means the Blue channel ('Z') may not get used (partially or wholly); if we look back to the information above we find that this is the channel that often corresponds to 'depth / height' ('slope').

So instead of using the blue channel what's done in these instances is to make use of a separate 24 bit gray scale (black to white toned) image which provides a more detailed 'height' (bump) map; it 'replaces' the information that would otherwise be contained in and subsequently read from an images blue channel. This height maps is then combined back in game with the normal map using any extra settings that might be added via the interpretation of 'shaders' (extra calculated depth for instance).

    Design note: There are several advantages to doing this;

        Better control over how the combined textures looks in game - textures can be easily tweaked with just a line or two of text rather than having to reedit the original source files.

        Tonal gray scale' range increases which allows greater 'macro' detail to be shown, especially at the higher texture resolutions. This is due to the separate height map image actually being in 24 bit (RxGxB - 8x8x8 bit) rather than just a single 8 bit colour image; in a 24 bit image each 8 bit channel has 256 shades of gray (in the case of a height map) so when you add them all together you get greater and greater tonal detail and colour range, even with a pure gray scale tonal range.

Very few games actually utilise normal maps in this way now, preferring instead to simply make use of the full range of available channels contained in an image for in game surface texture rendering. This is how Oblivion uses normal maps, it utilise the blue channel.

    Design note: It's important to note here that although other normal mapped games may not use the blue channel, as mentioned above, the channel itself may actually have 'data' in it; this basically means the data is generally being ignored (not used) by other game engines and renderers; the blue channel is rarely completely 'blank' (contains no data other than a flat uniform blue).

    Because Oblivion is using the blue channel it means it won't ignore the data it finds there; it's part of what Oblivion uses for the games 'parallax mapping' - the other part being the alpha channel of the diffuse image, along side the math involved, it's where the method gets it's height information from (as opposed to a separate gray scale images as mentioned above).


Where do Oblivion's parallax maps come from then? ^

So now we know what normal maps are that Oblivion actually uses then in the same way as any other game to add a sense of depth to surfaces in game we can now answer the open question of just where does Oblivion's parallax mapping come from.

The answer is that Oblivion's 'parallax maps' do not physically exist as separate 'maps' in the same way that other physical media does for the game engine (wall_d[iffuse].dds, wall_n[ormal].dds, etc.), its actually a specific utilisation of a texture channel that's present on another image, namely the alpha channel on the diffuse image (the "A" of the "RGBA" mentioned above); effectively the available 256 tones of black/white available in the 8 bit alpha channel are interpreted by the engine in such a way as to 'boost', or 'parallax', the sense of depth already present in the normal map. In layman's terms, that's all parallax mapping is doing in Oblivion, just boosting the sense of depth already present.

    Design note: as mentioned in the above, Oblivion's parallax mapping is not a technically correct implementation of 'true' parallax, it's an approximation of parallax's main feature - additional visual depth.

So Oblivion's parallax system consists of two components;

    Normal maps - actual physical media

    Parallax 'maps' - alpha channel present other media (diffuse image)

Hope this helps!

-- EDIT --
I just remembered... we can also put 'heightmap' parallax bump maps in the Alpha of the Normal in SpeedTree to get the most out of your Caps and leaves normals.  This is slightly different than the above mentioned parallax map in the alpha of the -diffuse-, but it functions the same way.  Your own HE test files have these 'bump' maps in the normal as well for your caps.

As you noticed, the default example textures have both a small margin and an alpha gradient towards the bottom of each tile in the texture.  This, combined with a small value in the "transparency" setting in HeroBlade helps circumvent the issue - even a sizeable border will likely not be enough to prevent any compression artifacts (in all cases) in the very small mips.

Actually, I notice there is no margin between quadrants on the HE stock images - just the gradient.  I used a gradient and added some 'space' as you suggested, but now my grass floats in space a few centimeters off the ground.  Is there a way for me to change the 'Z' axis of the grass overall in order to 'sink' it into the ground?  I'll have to try just using a gradient if there's no way to alter the z axis.  Is there something I can alter in a shader somewhere?

Thanks Again!

EDIT -- well, it looks like all I needed to do was to add that gradient and keep my dynamic details at a 10 transparency or higher to eliminate the texture bleed.  Adding a border unfortunately made the grass float, like I mentioned above - but with the quadrants right up to the edge + alpha gradient on the border edges = success!  Thanks for all of your help through this process.

The behavior you are seeing with dynamic details is most likely a direct result of the way that DDS compression effects the alpha channel.  All of the cases where I've been able to reproduce the behavior have had alpha from the top two tiles bleeding down into the bottom two.

As you noticed, the default example textures have both a small margin and an alpha gradient towards the bottom of each tile in the texture.  This, combined with a small value in the "transparency" setting in HeroBlade helps circumvent the issue - even a sizeable border will likely not be enough to prevent any compression artifacts (in all cases) in the very small mips.

If you either need to have alpha that goes right to the border with no margin or you even with a margin you're still seeing the "bar", the easiest solution is to manually update the alpha mip maps.  So, first you create the texture and export as DDS.  Then you open the DDS file, checking the "Load mipmaps" button.  Edit the alpha channel of the mip maps to fix the error (which comes from averaging pixel values to create the mip maps). Then, save the DDS again, making sure to check the "use existing mip maps" option.

As for the issue with SpeedTrees, I'm looking into it, but it appears to be the same issue.  If it isn't the source texture causing the problem, there is a section in the user manual which talks about settings to tweak: 

To correct this, adjust the "Inner scale" or "Outer margin" properties on the offending texture to give it a border of empty space. The textures bleeding through are usually opaque (high alpha values) to the very edge of the texture, such as branch cap textures, not the textures that you see the effect on (such as leaves in the example picture).
If a solid texture is detected on initial tree load, the "Inner scale" property will automatically be set to 0.9. However, in some cases this may not be enough.

So if there aren't any compression artifacts in the alpha, it may just be a speedtree setting that needs to be tweaked for that specific texture.

Wanted to post an update since both issues are now solved with workarounds:

My current workaround for the Dynamic Detail grass is this - pull each tile 8px from the edges of the quadrants in the image (16 for 1024 textures) and then add an alpha gradient to each one.  It adds a bit of extra work, but nothing a good pipeline can't solve.  This step makes the grass currently 'hover' in mid-air.

Second - your fix with SpeedTrees worked beautifully.  I changed "Inner Scale" on the cap textures from .9 to .86 (more if the cap texture is considerably smaller than the leaf texture) and it solved my problem.  Thanks for your help! Now I just have to figure out how to get rid of those pesky roots popping out of my billboards for no reason lol.

Art & Art Pipeline / Texture Settings for Diffuse and Normals
« on: May 30, 15, 12:46:41 AM »
Hello fellow devs! 
I have been making a plethora of textures for our game, and there are two issues that I'm seeing overall that I'd like to find out more information about.  [This is after heavy testing, wiki reading, and experience]

First Issue:
In the diffuse channel for materials, you can have Parallax Bumps/Bump Maps in Hero Materials, but I don't see any way to enable them for the terrain textures.  If you put an alpha channel in a diffuse currently (as DXT5), it asks like a gradient "Alpha Mask" property (which is cool, but our game doesn't need Alpha Mask for our terrain).  I would MUCH rather be able to put a true 'heightmapped' bump/parallax map in that Alpha channel.  I know what you're going to say: "norm maps are far superior.. etc." while as this is true, we all know that -normal map + bump map- is in combination, far superior to either alone.

Is there any way to do this?  I've tried pretty much every .dds filetype and setting to try to enable this function, but I'm not sure how to get the terrain shader to comply.

Second Issue:
I see that HE reads DXTnm files as RGBA instead of XY (GA) - but that it does indeed read them as DXT5 files.  Is there a plan in the future to enable this, since it's a normal function of DX?

Both of these issues surmount to this:
Hero Engine currently only lets you use compressed .dds files, which is fine for Diffuse, but when it comes to normals, they come out pixelated and lossy.  I'd like to be able to use DXTnm, but since that doesn't seem possible (especially because the spec being the alpha just gets wacky with the L/R normal channel being the spec in DXTnm) is there a way to get more out of my normals?  I know I can make them double the resolution, but in all honesty, I'd either like to use a non-compressed .dds at 1/2 resolution (or 1/4, whatever) for the normals, use DXTnm, or be able to at least add a parallax/bump to the diffuse.  Maybe there's a filetype i've missed that enables this?

EDIT -- Also, to give the devs more of an idea of what this combo does: 
The effect that I'm going for is good depth at extreme angles.  Parallax Bump + Normal = Good depth at extreme angles.  The normals by themselves do really really poorly at keeping dimension at extreme angles (which, if you're in first person - everything is extreme angles).

Any help would be awesome.  Love this engine!

Odyssey of Ydris

EDIT/UPDATE -- I got ARGB working.  It makes the files much larger, but lowering the resolution and keeping them uncompressed seems to do the trick!  Comparable file size, better normals!

I'm still hoping there's some info on the bump maps for diffuse, so let me know - thanks!

Interesting, the problem is specifically with the third mipmap?  I assume you are using the automatic generation of mipmaps option in the DDS exporter for Photoshop?  Can you post a screen shot of the alpha channel of one of the problematic textures - including the mip mapped versions?

I actually have mainly been using GIMP because I'm trying to better familiarize myself with the program, but for this bug, I get the same exact results whether the mips were automatically generated in PS with the Nvidia .dds plugin, or in GIMP with the GIMP .dds plugin.

Those look like the speedtree default MIP exports.

Yes, exactly!
The mips that I posted were 'opened' in PS, but they were generated by the SpeedTree Compiler with everything in 'default' .dds mode.

Here are the screenshots you wanted, HE-BENNETT.  The first two are the 'grass' textures.  You can see how the first image, which is my own, is solid alpha which makes the bug extremely obvious.  Other than that, it doesn't seem like there's any issue with the mips being different than the originals in the distance to the quadrant edge.

The second shot is of the default 'test' HE grass, which has a very distinct alpha gradient, which would make this bug invisible to you in testing unless the transparency in HE is set to '0' or very near it.

This last image is the Alpha layer of the SpeedTree default mip export, which pretty clearly shows that the alpha has plenty of room, and shouldn't be the problem.

Again, look at the same texture's diffuse version from my post above -- the third mip map is the only one where the 'green' background default border has failed at all and is 'blending' with the texture -- but this shouldn't be an issue if the Alpha is applying correctly, should it?  It would just be extra 'glow', not a -bar- across my textures.   And if it was a texture filtering issue, wouldn't it happen on the original texture or the first and even second mips?  So if the Alpha ISN'T the problem (because it looks like there's boatloads of room up there), then could it be possible for HE to be reading those mips Diffuse Texture's pixel locations improperly?  It only happens after you move the camera back a good distance from the texture in question.  If you can't replicate the problem, try turning on the wind -- it makes it pretty obvious in my world.  I don't think it's just the 3rd mip, it looks like it's everything after that mip as well, but it's hard to tell.

I was also talking to our programmer and he was wondering if, since you mentioned it was a hardware filtering issue -- is there a way to turn it off?

If it helps, there was another post about this topic, but only relating to SpeedTrees that was posted in December by a person with my same problem.  The trees that he imported himself from Max/Maya seemed to be working just fine, but his speedtrees 'all of the sudden' started doing this to him.


Pages: [1] 2