3rd party material combiners

[R Reynolds]

I can probably guess the answer but I have to ask; will SimbiontAM, atx & trb files that work in A:M v13, also work in A:M v16 64 bit?

[robcat2075]

V16 64 bit includes the Darktrees plugin so those should work. I tested one, it worked.

 

Other things, I suspect not, but that's why it's good you can have both 32 and 64 bit running with the same license.

 

 

Any particular items?

[John Bigboote]

For those newly looking in... Symbiont=Darktree.

[R Reynolds]

Any particular items?

I was quite attached to a few of the combiners from EnhanceA:M; e.g. A:M_Foliage, A:M_Bricks, A:M_Dirt. But the originating programmer said in an e-mail that it was "very unlikely" that he would do a 64 bit re-build.

 

...it's good you can have both 32 and 64 bit running with the same license

I agree. Lately I've had some success with rendering these textures on a simple planar model and applying them as decals on flattened models. So I suppose that will have to be my strategy to use them in 64bit A:M from here on.

[robcat2075]

...it's good you can have both 32 and 64 bit running with the same license

I agree. Lately I've had some success with rendering these textures on a simple planar model and applying them as decals on flattened models. So I suppose that will have to be my strategy to use them in 64bit A:M from here on.

 

Remember you can "bake" textures in place, no need to flatten.

[Rodney]

Rodger said:

Lately I've had some success with rendering these textures on a simple planar model and applying them as decals on flattened models.

 

Robert said:

Remember you can "bake" textures in place, no need to flatten.

 

For those looking in, it may be worth noting the difference between these two methods (Flattening and Baking of Textures).

- With Flattening, a human readable image is created that can be edited in most image editors

- With Baking, a complex grid of images is created that is not designed for use with most image editors

 

There are Pros and Cons to both methods but if planning to edit or paint onto the texture in a standard image editor Baking will only work if you've got a program that will properly interpret where all the grid shapes are suppose to reconnect. 3D paint programs like A:M Paint for instance.

 

In the case of these textures, if the material is applied to a one patch grid the results should be pretty much the same.

[pixelplucker]

A big advantage to baking is you can convert shaders to textures. I wish it was possible to do the same to a model that was uv mapped out and still preserve the uv's.

 

Now if someone could make an LSCM plug for unwrapping a model and add the feature of baking, it would allow for edibility of the texture in any paint program plus the compositing power of Baking.

 

I have had issues painting across seams in Painter and usually end up painfully flattening and unfolding a model by hand.

[robcat2075]

A big advantage to baking is you can convert shaders to textures. I wish it was possible to do the same to a model that was uv mapped out and still preserve the uv's.

 

I've been thinking of suggesting that as a feature, being able to bake using an already-applied decal as the template. But Steffen has a full plate right now.

[R Reynolds]

I used a number of 3rd party atx files successfully in v16_32bit but after putting Ander's MakeNormalMap001.atx in the same Textures folder, I started v16_32 and I got an error "Unable to load plug-in...MakeNormalMap001.atx". Does this mean this useful tool is no longer available or am I missing something?

[robcat2075]

I used a number of 3rd party atx files successfully in v16_32bit but after putting Ander's MakeNormalMap001.atx in the same Textures folder, I started v16_32 and I got an error "Unable to load plug-in...MakeNormalMap001.atx". Does this mean this useful tool is no longer available or am I missing something?

 

Not sure.

 

Is that on the forum somewhere, so i could try it?

[robcat2075]

I found the plugin.

 

I also get a "can't load" message in v16b

 

 

What does this do? Do you use it to create a normal map version of 3D objects that you then put on a flat plane?

[robcat2075]

You can render Normal Maps directly in A:M now with the Normal Map Buffer.

 

Here a simple demo.

 

-I modeled some stuff i wanted to convert to normal map

-put it on flat plane

-pointed an orthogonal camera at it (top window)

-rendered with "Surface Normals" and "Save Buffers" ON

-resulting normal buffer render shown in lower window.

 

 

NormalMapMakerDemo.prj

[NancyGormezano]

What does this do? Do you use it to create a normal map version of 3D objects that you then put on a flat plane?

 

yes. (create a normal map image to be used as a decal/patch image on some other surface)

 

It does not seem to have any problems in my version 32bit 16b.

 

Perhaps there is some problem/confusion on those systems that also have 64 bit?

Edited January 16, 2012 by NancyGormezano

[R Reynolds]

You can render Normal Maps directly in A:M now with the Normal Map Buffer.

Thanks for the tutorial Robert. That will serve my purposes nicely.

 

Perhaps there is some problem/confusion on those systems that also have 64 bit?

Maybe not in this case but I do have a confusing file structure in C:\Program Files\Hash Inc\v16.0.

 

I loaded v16b_64 first and I got a desktop icon for A:M64 and Netrender64. After I loaded v16b_32 the Netrender64 icon was replaced by the the icon for A:M32. Now there's two versions of most files ( e.g. Master.exe & Master_64.exe) all in the same folders. (I'm no expert but I'd have expected the 32 bit version to be in it's own folder in C:\Program Files (x86)\..) I have separate versions of RenderMessenger, RenderServer and RenderSlave. Ominously there's only one version of some routines (e.g. Netrender.cmd, master.log, uninstall.exe).

 

Once again I'm no expert but this doesn't seem proper. I was anticipating 16b_64 and 16b_32 to exist as completely separate applications with no shared files. Did I install v16b_32 incorrectly?

[robcat2075]

Once again I'm no expert but this doesn't seem proper. I was anticipating 16b_64 and 16b_32 to exist as completely separate applications with no shared files. Did I install v16b_32 incorrectly?

 

My 32 and 64 bit version are in separate folders. 32 is in Program Files (x86)/Hash Inc and 64 is in Program Files/Hash Inc folder

 

Although my plugin still didn't work.

 

Just top be proper I'd uninstall both (of course you'll save your master0.lic file before you do this) and run both installers again and pay attention to where the default installation address is going.

 

Note that if you manually navigate to a desired directory the installer may append an unnecessary folder level to the address. I'm not sure why. Double check it before you go on.

[NancyGormezano]

My 32 and 64 bit version are in separate folders. 32 is in Program Files (x86)/Hash Inc and 64 is in Program Files/Hash Inc folder

 

Although my plugin still didn't work.

 

Perhaps check Tools/Options/folders to see where A:M is looking for plugins, etc?

 

I only have 32 bit installed, & I installed 16b to C:\Program Files\Hash Inc\V16.0Subscription\.

 

However it appears that I also have another folder C:\Program Files\Hash Inc\V16.0, with all the sub folders. I don't know when that got created.

 

All the tools/options/folders are pointing to the subdirectories in the V16.0 folder (not the folder I installed 16b).

 

Perhaps your 32 bit version is looking in the wrong place for textures, shaders, hxt etc?

[robcat2075]

I only have 32 bit installed, & I installed 16b to C:\Program Files\Hash Inc\V16.0Subscription\.

 

Is that a name you created manually? I've never had "Subscription" show up when I've been running a an installer

[NancyGormezano]

I only have 32 bit installed, & I installed 16b to C:\Program Files\Hash Inc\V16.0Subscription\.

 

Is that a name you created manually? I've never had "Subscription" show up when I've been running a an installer

 

Yes I usually create my own folder names

[R Reynolds]

Just to be proper I'd uninstall both (of course you'll save your master0.lic file before you do this) and run both installers again and pay attention to where the default installation address is going.

Thanks for the tip, Robert. So I save my current copy of master0.lic and then copy it into the V16.0 folder (both 32 & 64 bit) after the installs? Does this also apply for someone such as myself who paid the premium for a "permanent" copy?

 

And speaking of saving files; I know *.sch files are the color schemes but where are the custom keyboard shortcuts saved?

 

And while we're talking about fresh installs, during the first installs there are check boxes pre-selected with "Register Extensions" and "Don't install additional plug-ins". Since they were checked by default I went with them but I'm curious; what in blazes do they mean and why are they optional?

[Fuchur]

Just to be proper I'd uninstall both (of course you'll save your master0.lic file before you do this) and run both installers again and pay attention to where the default installation address is going.

Thanks for the tip, Robert. So I save my current copy of master0.lic and then copy it into the V16.0 folder (both 32 & 64 bit) after the installs? Does this also apply for someone such as myself who paid the premium for a "permanent" copy?

 

And speaking of saving files; I know *.sch files are the color schemes but where are the custom keyboard shortcuts saved?

 

And while we're talking about fresh installs, during the first installs there are check boxes pre-selected with "Register Extensions" and "Don't install additional plug-ins". Since they were checked by default I went with them but I'm curious; what in blazes do they mean and why are they optional?

 

> Should be the same for permanent and subscription-owners, yes.

> Keyboardshortcuts are saved in the file "Master_64.MAC" / "Master.MAC" if I am not wrong... (I may be wrong so... just a dark memory from somewhere deep inside my head ).

> Registe Extenstions is an options which asks you if you want to open files with the extension "*.mdl"... (and so on) with A:M by default.

> Don't install additional plugin-ins" asks, if it should install a few more plugins of Steffen. It has been introduced because of some sort of error Steffen hat while programming v17 just in case it would be needed. I am not sure if it is still activly doing anything or needed so...

 

See you

*Fuchur*

[robcat2075]

Just to be proper I'd uninstall both (of course you'll save your master0.lic file before you do this) and run both installers again and pay attention to where the default installation address is going.

Thanks for the tip, Robert. So I save my current copy of master0.lic and then copy it into the V16.0 folder (both 32 & 64 bit) after the installs? Does this also apply for someone such as myself who paid the premium for a "permanent" copy?

 

I presume you could also do the authorization that involves pasting in the key you got in an email, but saving and using the master0.lic is faster.

 

Of course, you have both safely archived somewhere, none-the-less.

 

 

BTW, I think a proper path for 32-bit would resemble this

 

C:\Program Files (x86)\Hash Inc\V16.0

 

When you're done the Master.exe file should sit in that directory and not in some further directory in that.

 

 

and a proper path for 64-bit would be...

 

C:\Program Files\Hash Inc\V16.0

 

 

If, later on you wanted to have some other version also installed, perhaps v16a because you want to compare it with the current v16b, you coudl run the installer and manually specify and address like...

 

C:\Program Files\Hash Inc\V16.0a

 

 

I suspect your desktop icon gets set to whatever the last install location was, so you may want to manually create specific shortcut icons for each version you use.

 

 

 

 

 

 

And speaking of saving files; I know *.sch files are the color schemes but where are the custom keyboard shortcuts saved?

 

Those are in the .MAC file

 

And while we're talking about fresh installs, during the first installs there are check boxes pre-selected with "Register Extensions" and "Don't install additional plug-ins". Since they were checked by default I went with them but I'm curious; what in blazes do they mean and why are they optional?

 

I think "register extensions" tells Windows about A:M file formats so that when you double click on a .mdl file it knows to start up A:M

 

I forget what the "Additional plugins" are. Anyone know? Was it something to do with the automatic backup stuff? I'm also not sure what danger they represent.

 

I presume they could be had later by just running the installer again into the same dir

[R Reynolds]

Thanks for your help Robert. I set up the folders as you suggested and I'm almost there but as shown in the screen grab, Windows thinks there's a distinct version for everything but Netrender and it's pointing to the 32 bit version; probably because I installed it last. I assume to invoke 64 bit Netrender I need to start Netrender.cmd file in the C:\Program Files\Hash Inc\V16.0 folder.

[robcat2075]

Thanks for your help Robert. I set up the folders as you suggested and I'm almost there but as shown in the screen grab, Windows thinks there's a distinct version for everything but Netrender and it's pointing to the 32 bit version; probably because I installed it last. I assume to invoke 64 bit Netrender I need to start Netrender.cmd file in the C:\Program Files\Hash Inc\V16.0 folder.

 

That's what I got... the shortcut for 32-bit NetRender... also probably because I ran 32-bit installer last.

 

So I ran the 64-bit installer again (check the install path carefully, mine was still looking at the 32 bit folder) and now I have a shortcut for 64 bit Netrender instead.

 

Double check the path so you don't end up with an extra folder level appended.

[R Reynolds]

I'm declaring the experiment to have V16_32 running on the same machine to render 32bit atx and trb files as decals to be used in v16_64, a failure. Although I successfully loaded v16_32 in its own set of folders in C:\Program Files (x86) it was still looking for plug-in files in C:\Program Files. I manually re-directed it to look in Program Files(x86). When I opened v16_64 now it couldn't find its files since it was looking in Program Files(x86)! There appears to be some unanticipated cross-pollination when you have them both installed on the same machine. I'm not going to waste any more of my time debugging this and write off the loss of EnhanceAM as the price of the inevitable march of technology.

 

Once again thanks for the helpful suggestions.

[robcat2075]

I'm sure there's an easy solution. Let us know when you want to try.

[Rodney]

I'm declaring the experiment to have V16_32 running on the same machine to render 32bit atx and trb files as decals to be used in v16_64, a failure. Although I successfully loaded v16_32 in its own set of folders in C:\Program Files (x86) it was still looking for plug-in files in C:\Program Files. I manually re-directed it to look in Program Files(x86). When I opened v16_64 now it couldn't find its files since it was looking in Program Files(x86)!

 

Disclaimer: The following does not relate to Netrender because I haven't tested with Netrender. It *may not* related to v16 because I'm testing on v17Alpha 6. For that I'll have to check. Note that I have had both versions in the same file in v16 without any issues for the better part of a year.

 

The area I have bolded in the quote above shouldn't be an issue with Texture and Turbulence files because both 32bit and 64bit versions of the files can be in the same folder at the same time. 32bit A:M see the 32bit versions and 64bit looks for the 64 added in the file name (this was according to a note Steffen posted in a v16 release which prompted me to keep them in the same folder)

 

Note also that I have had both versions in the same file in v16 without any issues for the better part of a year.

 

That the 'Make Normal' plugin does not work in current versions has been confirmed and unless we all just have an older version it is likely it has not been updated. So don't test with that because it don't work, okay.

 

If there is one particular plugin that someone would like to test, please identify that and we can put a focus there. Testing all plugins at the same time is a bit more difficult.

[NancyGormezano]

That the 'Make Normal' plugin does not work in current versions has been confirmed and unless we all just have an older version it is likely it has not been updated. So don't test with that because it don't work, okay.

 

The makenormal plugin works in my ver 16b, 32 (reported above). My makenormal plugin is an old version. Whether it is correctly rendered or not, I can't say. But I am not having the same problems that Rodger is having.

 

I think the problem might be when 32 bit & 64 bit versions are both installed.

[Rodney]

The makenormal plugin works in my ver 16b, 32 (reported above). My makenormal plugin is an old version. Whether it is correctly rendered or not, I can't say. But I am not having the same problems that Rodger is having.

 

I think the problem might be when 32 bit & 64 bit versions are both installed.

 

Yes, thanks for the clarification Nancy.

AFAIK, the makenormal plugin should work fine in the 32bit version. It's with 64bit A:M that it won't work.

 

I think we've got to remove the makenormal plugin from the equation because it doesn't have a 64bit version.

That is a separate issue (especially if Aaver is the only one that has the plugin code).

So, that's a 3rd party problem.

 

Besides the Makenormal plugin (which I believe would work in 64bit A:M if there was a 64bit version) what plugins aren't working?

 

Can you upload your version of the MakeNormal.atx for testing?

[NancyGormezano]

Can you upload your version of the MakeNormal.atx for testing?

 

I do not have a special version of makenormal - it is probably the same as anyone else's (date is 2005). But anyhow here it is.

MakeNormalMap001.zip

Edited January 19, 2012 by NancyGormezano

[Rodney]

Thanks Nancy,

I'm pretty sure it's the same file but want to rule out that variable.

 

My test indicates that this file (the one Nancy uploaded for me) is not working in v17 (either 32 or 64bit).

[mouseman]

Sorry for coming late to the party. I had a similar problem to what Rodger described with the changing of the HTX folder setting on either 32 or 64-bit changing the property for both. I uninstalled both, cleared registry entries, and reinstalled (although possibly in a different order than the first time), and IIRC things are now separate. I have not tried to reproduce that behavior again (and I've been away from it for about 2 weeks due to vacation).

[R Reynolds]

...I uninstalled both, cleared registry entries, and reinstalled...

The symptoms made me suspicious that there was some confusion in the registry. At one point in the process, when I had both 32 and 64 bit versions installed, I tried using the more thorough Revo Uninstaller but it only "saw" one A:M to uninstall and it didn't say which version.

 

I try to avoid using regedit but when you say "cleared registry entries" do you just search for all occurrences of "Hash" and delete every entry from there down?

 

I ask only out of curiosity since I'm making good progress in grunging up a building's facade using native A:M materials as graphically manipulated decals. So I've overcome my desire for the 32 bit materials. 32 bit is dead! Long live 64 bit!