Amplify - Virtual Texturing for Unity Pro [Beta 1.2.1]

eem, unfortunately no. We haven't got around some Unity limitations yet. We're looking at web streaming as an alternative, after the release. iOS is also on the table for a post-release; not sure if it'll work but we're willing to try.

Seon, repeating textures are supported and should be working 100%. Could you provide more info?

 

Sure, I will send you a project to look at on Monday (weekend here already) that illustrates shading issues and texture banding on materials that have repeating UVs.

 

This is wierd, I tried amplify on some models with tiled textures and it was OK.

 

It's been supported since the beginning. The current workflow video, for example, uses the Sponza atrium which is pretty much tiled all over.

Could be low compression quality, which is adjustable or simply something I overlooked.

 

Diogo, I have sent you an email via the Unity Forum with a video that clearly shows the issues I am having with Amplify. Cheers

 

Also, why does Amplify set my Max size for each texture i'ts using dow to 64x64 ? I understand it might want it smaller than full res when packing it, but it should be working off a copy of my texture, not my original source... meaning it should never leave my source images modified from what I set them at, and I cant see any way of mass undoing that change, so I have to manually go through each texture and set them back to full res. Very frustrating.

 

Seon, were you using the latest revision (1.2.3r4)? Also, what GPU are you running on?

Textures are packed using their real size, as defined in the source image file. Textures you use in the scene are the ones ending up in the build so they need to be resized to an insignificant size on import, because ATM they cannot be excluded without breaking the whole editing process. What I can do is add an option to the converter to resize the textures back to their original size, while converting the materials back.

This seems to be a OSX/GL specific problem. I'll fire up the Mac and look into it today.

Thanks for taking the time to make the video.

 

Yes, 1.2.3r4, just downloaded prior to video capture. But it also showed the same issues in 1.2.2 and 1.2.1.

My MacPro (machine I captured video from) has an Nvidia Geforce 8800GT, but is also happening on my i7 MacBookPro with an Nvidia GT 330M card too.

The problem with you scaling the textures is that I still use some of them for other materials in other scenes and prefabs that don't use Amplify, so don't want them altered at all. I don't want to keep duplicate textures either as thats an asset nightmare. I understand now why you are sizing them down, but I would rather an option to leave them alone, as well as your offer of an option to put them back when Amplify shaders are removed.

Other than that, Amplify is a great tool !

 

Seon, I plugged my 8800GT (G92) today and was finally able to replicate the issues you are getting on OSX. It seems specific to this chipset/driver and OSX/GL, and I suspect that GT 330M is a derivative of G92 architecture, which could explain similar artifacts on both. I'll do my best to fix this today.

Also, regarding the textures, we'll add support for both options:
1) Return the texture to it's original size when released from the virtual texture. This will be on by default.
2) Avoid messing with texture sizes in the first place. This will be off by default.

This is a tricky situation, though. I assumed virtualized textures would not be used in non-virtualized materials. I guess I assumed too much. There's also a problem with sharing virtualized textures between different scenes which, while possible, will create duplicate data on both virtual textures. In the future, we'll be looking for more elegant, better integrated solutions that avoid redundancy.

There's also a fatal error related to auto-resizing VT which is already fixed. It'll be included in the next revision.

 

Another vote for iOS support here!

 

Awesome

 

I would like to ask about structure of VT. It is possible to make dif? For example if I am making update of my game, it is wasting to upload whole VT again just because of few small changes. Does VT structure allows to make dif file (i know that in some cases can be dif file bigger then original)?

 

Wicked, thanks Diogo. Appreciate your fast fixes and dedication!

We don't mind having duplicate virtual texture data in different scenes. No way around it we can see is we cant share the amplify file between Unity scenes.

 

I think when problem with fat32 limit is solved, it will be no problem to fit all textures you have to one VT and then there is no need to share anything, you have always one VT.

 

S7ARBVCK, duly noted

Demostenes, I wouldn't advise it. My recommendation is that you let Amplify Cache stay local. The incremental builder will try to avoid a full rebuild every time you get new textures from your colleagues by interpreting that difference itself. We know build times can get a bit overwhelming at the moment, but we're not even doing native code or multi-core builds yet, so that's our number one priority after the release. Going forward, we might provide central server software to manage the virtual texture asynchronously.

Seon, thanks. It's important to us that these obstacles are out of your way.

Now that I think of this sharing issue again, another way to look at it is that you can always share some textures by not virtualizing them, that way you leave more space in the VT for textures that are unique to that scene. However, we'll keep looking for a better way to do this, I'm sure it's possible to share one VT across several scenes. This feature is now in the backlog for post-release.

 

Is this restricted to Unity pro? Sorry for stupid question, but I would prefer not to browse through all the pages to see if someone else have asked this.

Also, is it really customary here to be so damned secretive about the pricing until the user goes onto the asset store? Wouldn't it be so much better if you guys -- most asset sellers -- to state the price in a more easily accesible fashion?

 

Gisle, Indeed. This plugin requires a couple of Unity Pro features like Render-to-Texture.

Believe me, it's not that we want to be secretive about the price. We're just not sure what distribution platform to use yet. When you consider that, for example, the Asset Store takes a hefty 30% cut it makes you think twice about pricing to make up for your investment. Having said that, the price might end up changing. There's also the possibility of a discount during a initial period.

-- edit: removed price info, no longer valid

However, I can tell you that all licenses will be studio-wide, you will be able to deploy it on any number of machines at no additional cost. Indie version is redeemable for an upgrade to a Pro license.

 

Actually I meant diff of already built texture. In case, I distribute patch to my players.

 

Well, we are indies and 128k limit is probably too little for us. Since you cant have more virtual textures at once and we have seamless world, we need to put everything in one VT. And we already have few thousands of 2k+ textures (probably reaching above fat32 limit even with good compression too). It wouldnt make much sense to put only part of textures into VT, it spoils elegancy of VT sollution. So pro is only way to go But 999 is quite overkill. Anyway there is no problem for us to pay through Paypal, no reason to support 30 percent asset store robbery.

 

Completely missed it, my bad. In that case, sure. The VT file is essentially a bunch of compressed tiles. Might be possible to diff efficiently depending on the algorithm. This could make an interesting feature now that you mention it.

Demostenes, we're still looking at our options and your feedback is important.

 

Yes, this would be interesting, because once you have published game, you have to deliver updates. And when you have VT with size of few GB, some kind of delta is must and if such system is built in, it can save some work.
On the other side each project will have different build workflow and patch building workflow, so it would be hard to offer some universal system, because you usually make diff patches in the end of building process. And you already have some tools for it. So I am not quite sure if such feature is worthy of that work. For example for us is sufficient, that VT structure allows to make diff, we can handle rest easily. For us there is only one feature I miss from amplify and this is solving fat32 limit. Rest is perfect, it perfectly fits our needs.

 

I can assure you the fat32 issue is one of the top priorities for post-release updates.

 

Diogo, I know you said iOS and web build support are not going to be anytime soon, but I am curious to know do you think itd even be possible? Especially web build. I am really interested in a solution for web builds that could stream gb's of texture data on demand. Almost like Google Earth, you enter an area, it will send the call and download the necessary texture data to fill in what your looking at. Do you think your plugin could ever at all evolve into being something that would work like that?

 

We'll be looking into iOS and Android support in the first couple of months after the release. I'm just not sure the hardware is there yet.

The problem with web builds is that we can't create self-contained packages due to asset bundle limitations. Streaming, on the other hand, is something we will be looking at. So yes, it's very likely that we end up supporting it.

 

Will this have Console support?

 

At the moment we can't afford devkits, much less console unity licenses.

 

Maybe the upcoming release of Unity 3.4 solves this problem:

And to be even more optimistic maybe they also improve the texture API... ;-)

xad

 

Not sure if it'll help. The problem right now is that I need to store up to millions of small objects. There isn't any unity asset type that efficiently allows that kind of layout, so I had to resort to a custom data file. Unless this changes, I'm not sure I'll be able to use that API. We'll see.

I'm really looking forward to the texture streaming feature and hoping that they'll translate into better texture upload support. Not holding my breath though.

 

Dang...

Allegorithmic Substance integration

Procedural textures are built directly into Unity. Substance procedural textures can be tweaked in Unity. You can even update your textures at run time. It can be used for anything from ageing effects on textures to customizable characters.

Are proccedural textures the same as Virtual Texturing?

 

http://blogs.unity3d.com/2011/06/16/unity-roadmap-2011/

 

No.
Procedural textures means that there is a set of numbers that defines what outcome you get, you don't use images or alike.

 

Like dreamora said. It's quite different. The purpose of VT is complete artistic freedom, at the cost of storage, whereas the purpose of procedural techniques is extremely high compression by constraining content creation to a compound of formulas and variables. Of course, substance makes the whole process somewhat artist friendly.

 

Bump for a new revision full of changes: 1.2.3r5

Changes

• Fixed preload error coming out of play when both scene and game viewports are visible.
• Fixed invalid placeholder page indices on automatic virtual texture resize.
• Fixed unity shader compiler bug in coverage/alpha-tested shaders by instruction reshuffling.
• Fixed dirty Amplify materials every time the game is played inside the editor.
• Fixed cannot CopyFrom() null camera.
• Fixed incremental build causing full rebuild when canceled.
• Fixed texture repeat and other issues on OSX/GL.
• Fixed shader precision issues for non-IEEE compliant SM3 GPUs.
• Fixed Amplify/Build not deploying VT in some cases.
• Fixed coverage/alpha-test related artifacts. Shadow passes are now VT aware.
• Fixed first frame. For real this time.
• Moved log settings, previously in AmplifyManager, to the new Amplify/Settings menu.
• Moved Amplify/Cleanup to Amplify/Tools window.
• Added option to avoid auto-resizing source textures. Should be used with caution.
• Added Amplify/Manual, Amplify/Feedback and Amplify/About menu options.
• Improved runtime performance by further reducing prepass overhead.
• Improved optimized VT deployment performance.
• Optimized VT deployment is now done via "Deploy Opt." button visible in the AmplifyTexture asset inspector, previously "Deploy".
• Regular Amplify/Build and Amplify/Build And Run now deploy a non-optimized version of the VT for faster iterations.
• Source texture assets are restored to their actual size when they are no longer virtualized. Manual reimport is still required, however.

I've underlined changes to issues reported by beta users.

Unfortunately, there have been some delays. However, we believe the user experience has been improved substantially in this revision. At the same time, we're working hard to get our website up and running and our techdemo is nearly ready for primetime.

The demo will feature detail from up to 10 GB of raw, mostly unique, texture data in a relatively small scene. Here's a small teaser:

​

 

How you do expect to deliver the tech demo with such a sice? with servers such MU or RS?

anyway, I first thought of using this just for surrounding terrain mapped with ortophoto maps but I'll consider it for full project (a big city) mapping if the tech demo convinces me.

great project.

 

Probably, yes. We'll provide a few mirrors and also a video. BTW, the virtual texture is compressed to less than 1 GB.

Cheers

 

How does it look with final relese?

 

Hi Demostenes, we're just finishing setting everything up. It will be up for sale during the course of the weekend.

 

Hey Diogo

What will the price be?

Plus how long after the release will "stamping" take to be added, so unique textures can be done?

 

maxfax, our revised prices are: $99 Indie and $349 Pro (plus VAT, if applicable) at our website, via Paypal. We'll have the site open for public as soon as possible, hopefully during tomorrow.

Regarding paiting/stamping, unfortunately I can't give you an exact date at this point. However, we've been researching into it on and off. We have a few important features already promised to finish first (e.g. fat32 support), plus a couple more plugins to release (both nearly finished). Only then we'll have enough time to work on it since it's such a demanding feature that requires our full attention.

 

Definitely a noteworthy piece of tech which we're evaluating. Integration with the Terrain engine is a must before we would adopt. We had considered the workaround of dropping the Unity terrain engine, making the terrain externally, and using a single mega-texture VT which would need to be 40960x40960. An example of doing this on your website would be interesting to a lot of people.

We're noticing a significant fps hit when layering Amplify with other plugins that also use RenderTexture's. e.g. Unisky. Understandable I suppose.

I got the bug where I'd disabled auto-resize source texture, but some textures were still resized to 64x64. iMac i7 running Windows 7, but it might be the chipset issue you identified in a previous post. No need to respond to this issue.

 

We are still looking at our options on what to pursue next. Terrain is definitely on the list. As is texture loading above 16K.

Amplify's perf hit can be adjusted by tweaking the property "Pages Per Frame" in the AmplifyRuntime component, located in your camera.

The textures are all resized when virtualized. After they're no longer virtualized, their size is restored but they still have to be reimported manually.

Just wanted to remind everyone that we've opened a new thread for the official release.