Sign in to follow this  
yckx

Unity MSVC std::vector and aligned data

Recommended Posts

I switched to the DirectXMath library when I switched to D3D11, and I'm running into this issue of Microsoft's std::vector implementation being incompatible with aligned data types. Looking around the 'Net it looks like the standard fixes are to avoid using std::vector, use a custom allocator, patch [s]vector::rebind[/s] vector::resize to take a const reference, or a combination of the latter two measures. But all the relevant pages I found were from 2008 or older.

So, what does the GD.net community suggest? And does anyone have a custom aligned allocator, or do I need to learn to write my own?

Share this post


Link to post
Share on other sites
Well, one solution would be not to use MSVC at all. If you are doing cross platform projects, you might as well be using MinGW on Windows, since you are likely using GCC already on other operating systems.

If you are not targeting Non-Microsoft OSes at all, you can still use MinGW.

If you must use MSVC, then you can replace the horrible Microsoft STL implementation with [url="http://www.stlport.org/"]STLport[/url].

Share this post


Link to post
Share on other sites
[quote name='yckx' timestamp='1317694320' post='4868796']
I switched to the DirectXMath library when I switched to D3D11, and I'm running into this issue of Microsoft's std::vector implementation being incompatible with aligned data types. Looking around the 'Net it looks like the standard fixes are to avoid using std::vector, use a custom allocator, patch vector::rebind to take a const reference, or a combination of the latter two measures. But all the relevant pages I found were from 2008 or older.

So, what does the GD.net community suggest? And does anyone have a custom aligned allocator, or do I need to learn to write my own?
[/quote]
If you have a specific additional memory allocation requirement (like a specific alignment) and you want to use a standard library container, you have to replace the default allocator with one that satisfies the additional requirement. This is not specific to any one C++ runtime. It is why allocators are a customization point in the standard library.

It is not difficult to write something that satisfies the allocator requirements, but you might want to have a good reference handy (like Josuttis) just in case.

Share this post


Link to post
Share on other sites
[quote name='Bregma' timestamp='1317695329' post='4868806']
[If you have a specific additional memory allocation requirement (like a specific alignment) and you want to use a standard library container, you have to replace the default allocator with one that satisfies the additional requirement. This is not specific to any one C++ runtime. It is why allocators are a customization point in the standard library.

It is not difficult to write something that satisfies the allocator requirements, but you might want to have a good reference handy (like Josuttis) just in case.
[/quote]

No, the problem OP is having isn't related to memory allocators, it's related to the fact that Microsoft's STL uses the wrong parameter types in functions like vector::resize, effectively making their STL completely incompatible with aligned types, regardless of what allocator is used.

Share this post


Link to post
Share on other sites
[quote name='lpcstr' timestamp='1317694794' post='4868800']
If you must use MSVC, then you can replace the horrible Microsoft STL implementation with [url="http://www.stlport.org/"]STLport[/url].
[/quote]
MSVC has a fairly decent standard library implementation (the days of the lawsuits that prevented Microsoft from bundling a conformant library with MSVC6 after the previous C++ standard was released have been over for quite some time).

STLport does not come close to conforming to the current C++ standard.

Share this post


Link to post
Share on other sites
One solution is to use a std::vector replacement. For example, the bullet physics source code contains a class called [font="Courier New"][url="http://www.bulletphysics.com/Bullet/BulletFull/classbtAlignedObjectArray.html"]btAlignedObjectArray[/url][/font], which is designed to solve your problem.
[quote name='lpcstr' timestamp='1317695646' post='4868807']No, the problem OP is having isn't related to memory allocators, it's related to the fact that Microsoft's STL uses the wrong parameter types in functions like vector::resize, effectively making their STL completely incompatible with aligned types, regardless of what allocator is used.[/quote]No, the problem OP is having is related to standard allocators not satisfying non-default allocation requirements -- this is the same problem no matter what compiler/STL implementation you're using.
For example, on GCC, if you use the non-standard [font="Courier New"]__attribute__[/font] syntax to specify a non-default alignment value, then [font="Courier New"]std::vector[/font] won't work out of the box any more, [i]due to the fact that this kind of structure alignment is non-standard[/i].

Secondly, your information about Microsoft's 'STL' being non-standards compliant is incorrect, as of about 5 years ago.

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1317696084' post='4868810']No, the problem OP is having is related to standard allocators not satisfying non-default allocation requirements -- this is the same problem no matter what compiler/STL implementation you're using.[/quote]

MSVC (9 and 10, at least) both pass resize's _Val parameter by value, not const reference. Consequently, even if you write a custom allocator, you get a compiler error warning that the parameter cannot be aligned. So, whilst the allocator is needed, it seems disingenuous to say that the library implementation is entirely faultless.

Share this post


Link to post
Share on other sites
[quote name='Bregma' timestamp='1317695717' post='4868808']
MSVC has a fairly decent standard library implementation (the days of the lawsuits that prevented Microsoft from bundling a conformant library with MSVC6 after the previous C++ standard was released have been over for quite some time).

STLport does not come close to conforming to the current C++ standard.
[/quote]

I was recommended STLport by multiple users here at GD.net just a year ago when I hade the [b]exact[/b] same issue when using MSVC's srd::vector with 16 byte aligned float structures. I had an appropriate allocator made up, but because MSVC's STL passes by value in vector::resize, it is impossible to get anything buy compiler errors out of it.

This problem doesn't exist with STLport or GNU STL, so I stand by my statements.

Share this post


Link to post
Share on other sites
[quote name='TheUnbeliever' timestamp='1317696821' post='4868817']MSVC (9 and 10, at least) both pass resize's _Val parameter by value, not const reference.[/quote]Does the standard specify the signature as: [font="Courier New"]void resize(size_type sz, T c = T()) [/font]?
On my current project, the 3 different compilers that we use all comply with the above signature.

Share this post


Link to post
Share on other sites
[quote name='lpcstr' timestamp='1317697825' post='4868823']
[quote name='Bregma' timestamp='1317695717' post='4868808']
MSVC has a fairly decent standard library implementation (the days of the lawsuits that prevented Microsoft from bundling a conformant library with MSVC6 after the previous C++ standard was released have been over for quite some time).

STLport does not come close to conforming to the current C++ standard.
[/quote]

I was recommended STLport by multiple users here at GD.net just a year ago when I hade the [b]exact[/b] same issue when using MSVC's srd::vector with 16 byte aligned float structures. I had an appropriate allocator made up, but because MSVC's STL passes by value in vector::resize, it is impossible to get anything buy compiler errors out of it.

This problem doesn't exist with STLport or GNU STL, so I stand by my statements.
[/quote]

Standing by observation is a good thing but understanding the problem is probably more important in this case. Basically the problem has nothing to do with the STL of VC but in a fundamental issue of C++ and how to interpret a semi-vague standard in this area. The STL definition of an allocator has nothing to do with memory alignment, worse, by definition the amount of allocation is requested by using "sizeof". So, a fully compliant STL only allows you to specify the initial address of a vector by overloading the allocator, it will (by standard) use sizeof to figure out how much memory to allocate for each element and as such the delta between elements in that memory. The STL versions you mention support "hacks" which work with padded structures instead of the basic "sizeof", it makes sense because that is "usually" what you want, but it is actually "against" standards compliance.

C++ doesn't support "alignment" directly, that's all done via extensions using pragma's, attributes etc. All such concepts are compiler specific and while rather stupid, VC's STL implementation doesn't take into account for these items. Stupid versus non compliant are very different things in this case. VC's STL since 2k8 versions have been exceptionally compliant.

The difference here is critical. VC's STL is actually the more compliant in this case, unfortunately it is not the most usable for what you want to do with it. Which version is better? One is very compliant and the others are cheating to be more usable. Given all the complexities in C++, I prefer more compliance so there are fewer invisible things going on behind my back.

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1317699849' post='4868836']
[quote name='TheUnbeliever' timestamp='1317696821' post='4868817']MSVC (9 and 10, at least) both pass resize's _Val parameter by value, not const reference.[/quote]Doesn't the standard specify the signature as: [font="Courier New"]void resize(size_type sz, T c = T()) [/font]?
On my current project, the 3 different compilers that we use all comply with the above signature.
[/quote]

I don't have access to a copy of the standard, so I can't honestly say. It's entirely plausible. In that case, maybe the word 'fault' isn't right to use, certainly not of the library. My point was really just that the combination of library and compiler mean that writing a custom allocator is insufficient to solve the problem - you must also patch vector to take a const reference. This was definitely the case with MSVC9. The library in 10 has stuck with the same signature, but perhaps the compiler allows alignment of function parameters. I can't remember if I've tried.

So, yeah - perhaps my wording is a little strong, but there's at least one additional problem which we don't have enough information (define 'incompatible', and which development environment are we using) to rule out. :o)

Share this post


Link to post
Share on other sites
[quote name='AllEightUp' timestamp='1317701333' post='4868845']
Standing by observation is a good thing but understanding the problem is probably more important in this case. Basically the problem has nothing to do with the STL of VC but in a fundamental issue of C++ and how to interpret a semi-vague standard in this area. The STL definition of an allocator has nothing to do with memory alignment, worse, by definition the amount of allocation is requested by using "sizeof". So, a fully compliant STL only allows you to specify the initial address of a vector by overloading the allocator, it will (by standard) use sizeof to figure out how much memory to allocate for each element and as such the delta between elements in that memory. The STL versions you mention support "hacks" which work with padded structures instead of the basic "sizeof", it makes sense because that is "usually" what you want, but it is actually "against" standards compliance.

C++ doesn't support "alignment" directly, that's all done via extensions using pragma's, attributes etc. All such concepts are compiler specific and while rather stupid, VC's STL implementation doesn't take into account for these items. Stupid versus non compliant are very different things in this case. VC's STL since 2k8 versions have been exceptionally compliant.

The difference here is critical. VC's STL is actually the more compliant in this case, unfortunately it is not the most usable for what you want to do with it. Which version is better? One is very compliant and the others are cheating to be more usable. Given all the complexities in C++, I prefer more compliance so there are fewer invisible things going on behind my back.
[/quote]

Thanks for the clarification. Standards aside, OP as well as many of us find ourselves needing dynamic arrays of aligned data, so this is an issue which needs a solution.

Share this post


Link to post
Share on other sites
[quote name='TheUnbeliever' timestamp='1317701806' post='4868848']
So, yeah - perhaps my wording is a little strong, but there's at least one additional problem which we don't have enough information (define 'incompatible', and which development environment are we using) to rule out. :o)
[/quote]
"Incompatible" means I'm getting this error:
[b]error C2719: '_Val': formal parameter with __declspec(align('16')) won't be aligned[/b]
I apologize for not posting it earlier.

And I'm using MSVC 2010 Express on a Win7 64-bit machine (but compiling for 32-bit debug).

I guess I'm going to look into alternative containers and custom allocators and see which I prefer.

Share this post


Link to post
Share on other sites
[quote name='yckx' timestamp='1317703472' post='4868852']"Incompatible" means I'm getting this error:
[b]error C2719: '_Val': formal parameter with __declspec(align('16')) won't be aligned[/b]
I apologize for not posting it earlier.[/quote]

Writing a custom allocator won't fix this: you either need to, standard be damned, patch the line in the header (the error presumably points to it) or use a replacement container. Either way, you will need a custom allocator as well.

Share this post


Link to post
Share on other sites
[quote name='TheUnbeliever' timestamp='1317701806' post='4868848']
I don't have access to a copy of the standard, so I can't honestly say. It's entirely plausible.
[/quote]
For the record, ISO-14882 says this.
[23.3.6.2](11) [font="Courier New"]void resize(size_type sz, const T& c);[/font]

If the Microsoft implementation does not meet this requirement, it is nonconforming (ie. broken). Very unfortunate. The OP's problem will still obtain with other implementations because he needs to provide a custom allocator.

Also, for the record, STLport does not implement about 50% of the current standard library.

Share this post


Link to post
Share on other sites
[quote name='yckx' timestamp='1317703472' post='4868852']
[quote name='TheUnbeliever' timestamp='1317701806' post='4868848']
So, yeah - perhaps my wording is a little strong, but there's at least one additional problem which we don't have enough information (define 'incompatible', and which development environment are we using) to rule out. :o)
[/quote]
"Incompatible" means I'm getting this error:
[b]error C2719: '_Val': formal parameter with __declspec(align('16')) won't be aligned[/b]
I apologize for not posting it earlier.

And I'm using MSVC 2010 Express on a Win7 64-bit machine (but compiling for 32-bit debug).

I guess I'm going to look into alternative containers and custom allocators and see which I prefer.
[/quote]

The above error you received is a problem with the Visual studio compiler cannot guarantee 16 byte alignment for variables that are copied on the stack. A fix to your problem is to compile your application as a 64 bit compile and you will not receive any errors. I would suggest going for 64 bit compiles as that is going to be the dominant os version.

You can read this http://thetweaker.wordpress.com/2010/05/05/stdvector-of-aligned-elements/

Share this post


Link to post
Share on other sites
[quote name='Bregma' timestamp='1317727257' post='4868946']
If the Microsoft implementation does not meet this requirement, it is nonconforming (ie. broken). Very unfortunate.
[/quote]
After doing some more informed Googling, it appears that this is a relatively recent change to the standard, and that Microsoft actually complied here while many other vendors chose not to for the sake of usability. I can post a link later today that goes into more detail.

[b]Edit:[/b] Here's the [url="http://thetweaker.wordpress.com/2010/05/05/stdvector-of-aligned-elements/"]blog entry[/url] and [url="http://thetweaker.wordpress.com/2010/08/15/stdvector-of-aligned-elements-revisited/"]followup[/url] I was talking about. I'm not sure when the revision occurred, but it looks like Microsoft's implementation of std::vector::resize() was compliant until the standard was revised.

Share this post


Link to post
Share on other sites
[quote name='smasherprog' timestamp='1317736303' post='4868989']
A fix to your problem is to compile your application as a 64 bit compile and you will not receive any errors.
[/quote]
I was under the impression that one could not compile for 64-bit applications with the Express edition of MSVC.

Share this post


Link to post
Share on other sites
[quote name='lpcstr' timestamp='1317702282' post='4868849']
Thanks for the clarification. Standards aside, OP as well as many of us find ourselves needing dynamic arrays of aligned data, so this is an issue which needs a solution.
[/quote]

I completely agree that we need a solution, sorry if I sounded like I was defending some gallant adherence to standards, that's not the case at all. I actually use a custom vector container because of these problems. If STL had been written with a policy based front end (i.e. not just the allocator but also internal behavior), it would have greatly helped correct the deficiencies and allow stl containers to adapt better to ongoing changes and requirements in programming. Unfortunately they were not and now they are starting to show deficiencies. (Personally, I thought they had a LOT of deficiencies for optimization reasons and hence wrote my own in many places as drop in replacements when it makes sense.)

Look at the basic problems with std::vector as examples:

1. Pod items are detected automatically and in cases where something "looks" non-pod but could be treated as pod, you can't do anything to change the STL behavior of copy construct/delete, which in "many" cases is stupid overhead. Deal with it or use a non-stl container.
2. No way to define stable/non-stable erasure. 90% of the time I don't care about stable erasures in a vector and as such some STL variations supply "fast_erase" or related functions which just move the last element to the erased elements location instead of shifting everything down by one. Of course, unless you target a single platform, you can't always use this and that causes big performance differences between platforms/libraries.
3. POD detection is so flakey given the lack of decent metadata in C++ that a huge portion of the time STL guesses wrong and by definition "most" of your std::vector's are doing stupid work behind your back.

This is a huge problem with C++ that needs to be corrected to make stl something even performance critical applications can/should use. Adding the concept of "alignment" requirements to C++ is also extremely important.

Share this post


Link to post
Share on other sites
FWIW, I decided to use btAlignedObjectArray; learning to write a custom allocator is a task for another day. I'm still fairly new to the use of aligned memory and whatever eases the curve is a short-term win.

Share this post


Link to post
Share on other sites
After reading this thread back in October, I had [url="https://connect.microsoft.com/VisualStudio/feedback/details/692988/std-vector-resize-should-take-a-const-reference"]submitted a bug report to Microsoft[/url] about vector resize not taking a const reference. [url="https://connect.microsoft.com/VisualStudio/feedback/details/173440/std-vector-resize-should-take-a-const-reference"]Some research[/url] had shown that it had been previously requested to be changed to a const reference, but it had been rejected to be fixed.

As you can see by the first link, this wll be fixed in VC11.

[quote]
Hi,

Thanks for reporting this bug. We've fixed it, and the fix will be available in VC11.

Amusingly, when this was originally reported in July 2006 (months before I joined the VC team), this was indeed By Design. C++03 23.2.4.2 [lib.vector.capacity]/6 specified:

void resize(size_type sz, T c = T());

Now, C++11 23.3.6.3 [vector.capacity]/9, 11 specifies:

void resize(size_type sz);
void resize(size_type sz, const T& c);

This change was introduced in March 2008's Working Paper N2588.

If you have any further questions, feel free to E-mail me at stl@microsoft.com .

Stephan T. Lavavej
Visual C++ Libraries Developer
[/quote]

Share this post


Link to post
Share on other sites
[quote name='Rattrap' timestamp='1320504979' post='4880788']
As you can see by the first link, this wll be fixed in VC11.
[/quote]

I just had a quick check - this is in the version of <vector> in the vc11 developer preview.


Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Announcements

  • Forum Statistics

    • Total Topics
      628395
    • Total Posts
      2982437
  • Similar Content

    • By toadvine
      I'd like to start building a 2D game, very small, just pixel art. I know python/javascript/tiny bit of HTML and I've started learning C++. I'm a long way from starting officially, I've just been making mini-projects to practice & drawing up concept art/gameplay storyboards. I'm just wondering if I'm off with the C++ for the game's programming, or if I should know certain things before starting.
      The game would be very small, I just want to get started trying out some actual work before college.
      Some other info: I'm working by myself on this, and going into game design/programming next year for college. I'm a high school student with a few years of experience just working by myself making small projects, drawing up stuff, so I really don't know much and I'd appreciate any tips.
      Thanks a bunch!
    • By Daerst

      SWARMED is a Zombie-themed RPG / RTS currently in development using Unity 3D. We love Dwarf Fortress (though we have no illusions that SWARMED will reach the same level of complexity), roguelikes, old-school point & click RPGs and real-time strategy games. We aim to cross genre-borders here and there and give some twists to the old Martinis every gamer has been drinking since the 1980s, metaphorically.
      Single player, 3D graphics and adjustable top-down camera - old-school RPG / RTS feeling Take control of a core group of survivors after the outbreak Encounter Zombies that are a real threat, no machine-gun massacre. Don't get swarmed! Build a safe zone anywhere with a highly flexible build system: campsite, lighthouse, school, or fence a whole village Grant asylum to other survivors that you meet and make them a part of your community Achieve sustainability in your safe zone and go on supply runs with your survivors
      Development
      The core team of recently founded indie studio Three Eyed Games currently consists of one writer, two artists and two programmers, based in Germany. We are in our mid-20s with professional experience in developing interactive 3D applications with Unity.
      SWARMED will feature both a 'free-play mode' and a campaign with mid-sized maps that leads the player through a story while explaining the gameplay and introducing him / her to the survivors: a core group a few 'hero' characters the player starts with (each one a detailed character with backstory, hopes and dreams), and more 'heroes' (total not more than 20, probably less) that the player can meet on the journey. In addition, randomly generated NPCs (less detailed and not directly controllable, similar to the way Dwarf Fortress handles its dwarves) can join your safe zone – if you let them.
      We plan to release a few 'Origin' prototypes that showcase individual gameplay systems and meanwhile give a gentle introduction to the characters you will meet in the game. Origin I, showcasing the build system and many fundamental elements like character controls and interactions, is finished and will be released soon. Next up, we're working on the dialog system to be presented in Origin II. Get in touch and we will provide more details and a playable version.
      We want you!
      We seriously think you should join the fun! We are looking for:
      Level Designers / Environment Artists, preferably with experience in Unity and procedural asset creation. Design and build maps with interesting visuals and proper pacing. 3D Artists. Our shacks, items and the dead guys' faces could use some plastic surgery. Can you do that? Writers. We have a bunch of characters to detail and a story to write ahead of us. Game Designers. We have a rough game design sketched out that needs improvement and completion. We need a balanced combat system, trees for constructions, workshops and character skills etc. PR & Community Managers, preferably with web development experience. We want to build a community around the game, and we need you to plan and manage this (with the help of the rest of the team, of course). 2D Artists / UX Designers, preferably with Unity UI experience. Our menus still look pretty dull, and we don't like that. We also need concept art for characters and iconic game moments to define their look and feel. Coders. If you know your way around Unity and C#, there are lots of challenging things to be done. You will work closely together with the two programmers already on the team to get going quickly. Please drop me a message or contact info@three-eyed-games.com
    • By sveta_itseez3D
      itSeez3D, a leading developer of mobile 3d scanning software, announced today a new SDK for its automatic 3D avatar generation technology, Avatar SDK for Unity. The Avatar SDK for Unity is a robust plug-n-play toolset which enables developers and creatives to integrate realistic user-generated 3D avatars into their Unity-based applications. SDK users can allow players to create their own avatars in the application or integrate the SDK into their own production processes for character design and animation.
      “Virtual avatars have recently become increasingly popular, especially in sports games and social VR apps. With the advance of VR and AR, the demand to get humans into the digital world is only increasing”, said Victor Erukhimov, itSeez3D CEO. “Our new Avatar SDK for Unity makes it super-easy to bring the avatar technology into any Unity-based game or VR/AR experience. With the Avatar SDK for Unity now every developer can bring face scanning technology into their games and allow players to create their own personalized in-game avatars, making the gameplay much more exciting and immersive.”
      Key features of the Avatar SDK for Unity:
      Automatic generation of a color 3D face model from a single selfie photo in 5-10 seconds (!). Works best with selfies, but can be used with any portrait photo.
      Shape and texture of the head model are unique for each person, synthesized with a deep learning algorithm crafted by computer vision experts
      Head models support runtime blendshape facial animations (45 different expressions)
      Generated 3D heads include eyes, mouth, and teeth
      Algorithms synthesize 3D meshes in mid-poly resolution, ~12k vertices, and ~24k triangles
      Six predefined hairstyles with hair-recoloring feature (many more available on request)
      Avatar generation API can be used in design-time and in run-time, which means you can allow users to create their own avatars in your game
      Cloud version is cross-platform, and offline version currently works on PCs with 64-bit Windows (support for more platforms is coming soon)
      Well-documented samples showcasing the functionality.
       
      Availability
      The Avatar SDK for Unity is offered in two modes - “Cloud” and “Offline”. The “Cloud” version is available at http://avatarsdk.com/ and the “Offline” version is available by request at support@itseez3d.com.
      ###
      About itSeez3D
      At itSeez3D, we are working on the computer vision technology that turns mobile devices into powerful 3D scanners. itSeez3D has developed the world's first mobile 3D scanning application that allows to create high-resolution photorealistic 3D models of people's' faces, bodies and objects. The application is available for iOS and Windows OS mobile devices powered with 3D cameras. In 2016 the company introduced Avatar SDK that creates a realistic 3D model of a face from a single selfie photo. To learn more about itSeez3D scanning software and 3D avatar creation technology, please visit www.itseez3d.com and www.avatarsdk.com.

      View full story
    • By sveta_itseez3D
      itSeez3D, a leading developer of mobile 3d scanning software, announced today a new SDK for its automatic 3D avatar generation technology, Avatar SDK for Unity. The Avatar SDK for Unity is a robust plug-n-play toolset which enables developers and creatives to integrate realistic user-generated 3D avatars into their Unity-based applications. SDK users can allow players to create their own avatars in the application or integrate the SDK into their own production processes for character design and animation.
      “Virtual avatars have recently become increasingly popular, especially in sports games and social VR apps. With the advance of VR and AR, the demand to get humans into the digital world is only increasing”, said Victor Erukhimov, itSeez3D CEO. “Our new Avatar SDK for Unity makes it super-easy to bring the avatar technology into any Unity-based game or VR/AR experience. With the Avatar SDK for Unity now every developer can bring face scanning technology into their games and allow players to create their own personalized in-game avatars, making the gameplay much more exciting and immersive.”
      Key features of the Avatar SDK for Unity:
      Automatic generation of a color 3D face model from a single selfie photo in 5-10 seconds (!). Works best with selfies, but can be used with any portrait photo.
      Shape and texture of the head model are unique for each person, synthesized with a deep learning algorithm crafted by computer vision experts
      Head models support runtime blendshape facial animations (45 different expressions)
      Generated 3D heads include eyes, mouth, and teeth
      Algorithms synthesize 3D meshes in mid-poly resolution, ~12k vertices, and ~24k triangles
      Six predefined hairstyles with hair-recoloring feature (many more available on request)
      Avatar generation API can be used in design-time and in run-time, which means you can allow users to create their own avatars in your game
      Cloud version is cross-platform, and offline version currently works on PCs with 64-bit Windows (support for more platforms is coming soon)
      Well-documented samples showcasing the functionality.
       
      Availability
      The Avatar SDK for Unity is offered in two modes - “Cloud” and “Offline”. The “Cloud” version is available at http://avatarsdk.com/ and the “Offline” version is available by request at support@itseez3d.com.
      ###
      About itSeez3D
      At itSeez3D, we are working on the computer vision technology that turns mobile devices into powerful 3D scanners. itSeez3D has developed the world's first mobile 3D scanning application that allows to create high-resolution photorealistic 3D models of people's' faces, bodies and objects. The application is available for iOS and Windows OS mobile devices powered with 3D cameras. In 2016 the company introduced Avatar SDK that creates a realistic 3D model of a face from a single selfie photo. To learn more about itSeez3D scanning software and 3D avatar creation technology, please visit www.itseez3d.com and www.avatarsdk.com.
    • By Canislupus54
      I'm looking for programmers for an rpg I want to make. If you're wondering what "semi-turn based" means, it means that you take turns, but instead of a rigid back and forth like Pokemon, a timer determines when you can act, a sort of modernization of the classic Final Fantasy Active Time Battle system. Right now, I'm looking for programmers to create a prototype of both the combat system and the movement outside of combat. Preferably for Unity C#. Concept artists, particularly for characters, and writers to help me flesh out the character and story aspects, would also be helpful.
      Here's a concept doc to fully explain things: https://docs.google.com/document/d/1ObDMAUWsndSAJ1EpQGRDxtR8Xl9xPotx89OZ0sgRaIw/edit?usp=sharing
      If you can fill another role and are interested, feel free to let me know as well.
      At the moment, this is purely a hobby project, with no payment planned. If we produce something we feel we can release, then of course we'll work out something for compensation. But, again, don't join this project counting on payment.
      If you're interested, contact me on here, or at jordestoj@yahoo.com . Thanks.
  • Popular Now