Creating your own characters

 characters, chatbot designer, Documentation  No Responses »
Oct 252011
 

It’s possible to create your own characters for the chatbot designer app. The process consists out of 2 parts: first you need to create a set of images, once that’s done, you need to make a ccs file that combines all the images.

Images

The animations and visemes are stored as a series of images which are displayed in rapid succession, much like how old school film works. Before you can display these images though, they need to be created. Now, in the olden days, they used to have big chunky camera’s for that. Things have changed a bit since. We can use tools like DAZ3d, Poser, Blender,…

Content

What you put in the images is entirely up to you. There aren’t many limits with respect to content in the sense that there aren’t any ‘expected’ parts. That said, since we are dealing with chatbots, I’d try to put in something resembling a mouth somewhere, just to get some lip-syncing working. Most 3D tools these days, come with some way to manipulate mouth positions. The designer uses 21 different images for lip-sync (+ 1 for silence, which is actually the background image). Most 3D tools only provide morphs for 16 mouth positions. The remaining 5 visemes can be created by reusing other images or by creating your own, if the 3d app allows it. Here’s a good visual overview of all the visemes.

Animations like blinking eyes or moving hair also need to be exported from your 3D package as a series of images. Luckily most 3d software provides a feature to just that. Also, some animations can use the same image multiple times, it’s always best to reuse the same image in those cases, to save memory. For instance, an eye blink can be done with 2 or 3 images: eye fully open is provided by the background, half closed and fully closed.

File formats

Currently, the following file formats are supported:

BMP bitmap
GIF Graphics interchange format
JPEG Joint photographics experts group
PNG Portable network graphics
TIFF Tagged Image file format

It should also be possible to use xaml files (to create flash typed characters) , but this is not yet tested and will most likely not yet work. Give me a shout if you would like to do this.

Processing

Once you have created all the images, it’s best to process them a little further. At this stage, every image always uses up the full viewable area of the character. That’s ok, if all you want to do is lip-sync and possibly a little animation during idle times. But in this setup, your character can’t blink while speaking. To accomplish this, we need to cut out only the valid parts of each image and make the rest transparent. This way, the system can overlay multiple images and create the illusion of different parts moving at the same time.
Another added advantage of this process is that it usually (depending on the file type) shrinks the file. PNG files, when edited with the correct tools, will use less space if there is a bigger transparent area.

There are multiple ways you can crop the images. You can use the eraser tool found in most bitmap editing tools like paint.net.  Though, I’ve noticed that at least some versions of Photoshop don’t shrink png files when using the eraser, so that’s maybe not the best tool for the job. Personally, I used a little home-made app to do the Capturejob. You can download it from here.

It’s very simple to use. As you can see on the screenshot, there are 2 big buttons to the left which contain the source images. Press on each button to load the images. The top image should contain the root, in the bottom, you put the images that need to be cropped. To the right, on top, you see the result for the currently selected target image (seen in the bottom button). With the slider, you can scroll through the loaded images.
On the next line, there is a checkbox and a slider. These control the calculation process: do you want the parts of the image that are different or the same, and with the slider you select the tolerance level used to calculate the difference. When you put the slider fully to the left, there is 0 tolerance, meaning that there can be no difference between the pixel in the source image and that of the image that needs cropping. Put the slider fully to the right and the difference has to be very big.
Finally, with the button labeled ‘save’, you can save the processed images to a directory that you select (the original files are kept).

Depending on the way that the images are rendered in the 3D package, the file format and the quality of the rendering engine, there can be a bigger or smaller difference between parts of the images that should be the same. That’s why you normally have to play a little with the tolerance level. The lower, the better. Sometimes it’s better to keep a lower tolerance level and manually remove the remaining dots with an eraser in a bitmap editing package.

CCS file

When you’re ready with your images, it’s time to put them all together, a bit like a collage. Unfortunately, there currently isn’t yet a ready-made tool for this, so you are gonna have to do a little xml writing. Fortunately, there’s a lot of copy paste involved. The outer xml tag, the start of the file, is a <Character> tag, like so:

<?xml version="1.0" encoding="utf-8"?>
<Character xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
</Character>

Now, Let’s go over each section in order of the file content:

Character Info

The first section, and the easiest, is the character information. This is how it looks like:

  <CharacterInfo>
    <Name>Mika</Name>
    <Author>Ady Di Pierro</Author>
    <Copyright>Copyright 2011 Ady Di Pierro</Copyright>
    <License />
    <AuthorWebsite>http://www.laticisimagery.com.au/</AuthorWebsite>
    <CreationDate>2011-08-07T14:43:26.602+02:00</CreationDate>
    <LastUpdateDate>2011-08-07T14:43:26.602+02:00</LastUpdateDate>
    <Rating>
      <Rating>Unknown</Rating>
      <Sexual>false</Sexual>
      <Violence>false</Violence>
      <Other>false</Other>
      <Description />
    </Rating>
    <OnlineOptions>
      <OnlineCharacterBaseUrl />
      <PreferredWidth>150</PreferredWidth>
      <PreferredHeight>150</PreferredHeight>
    </OnlineOptions>
  </CharacterInfo>

Just copy the above and paste it into your xml file, just under <Character>. This part only contains reference information about the character: what’s it’s name, who designed it, what’s the licence, possibly a website,… All of the info in this section is optional, you can leave the tags empty, but it’s best to include them. This information, by the way, is displayed in the popup window on the ‘chatbot window’ (the button in the lower-left corner on the images window).

Online options are currently still skipped but will probably be used in future, online versions.

Background

<Background>
   <ImageResource>images\Kima00.png</ImageResource>
   <ImageResource>images\KimaEars.png</ImageResource>

</Background>

The background section defines the images that should be used as background (obviously). 2 things worth mentioning: a background is defined as an ImageResource. This is used often throughout the file. Whenever you want to reference an image file, you use this element. The text part of the xml element defines the relative path to the image (that is relative to the CCS file).

Also, and that’s perhaps the weirdest part, you can declare multiple backgrounds. Every image in this list will be displayed as a background, unless an animation turned one of the images off. And that’s the main usage of having multiple backgrounds: so that animations can turn part of the background off while playing. A good example are Mika’s ears.  They are drawn in a separate background image, so that the ‘flip-ears’ animation, can hide the background-ears while it’s playing. We do this cause some images in the animation sequence are smaller then the ears in rest, which would otherwise give ugly results with half an ear overlapped and the rest still visible. I’m certain there are plenty of other cool tricks to done with this feature. Hiding a background image is explained in the ‘Animations’ section.

Animations

The ‘Animations’ section is one of the bigger parts of the file. This is where you declare all the animation sequences available to the character for emotional expressions and idle times. The background animations (which run all the time, not jus at idle times), are declared somewhere else. Anyway, here’s how an animation definition looks like:

  <Animations> 
    <Animation>
      <AnimationFrames>
        <AnimationFrame>
          <Duration>5</Duration>
          <ImageResource>images\other\Kima Ears (01).png</ImageResource>
          <VisemeGroupName/>
        </AnimationFrame>
          <Duration>5</Duration>
          <ImageResource>images\other\Kima Ears (01).png</ImageResource>
          <VisemeGroupName />
        </AnimationFrame>
      </AnimationFrames>
      <EnableFrameSpeaking>true</EnableFrameSpeaking>
      <HoldLastFrameForSpeak>false</HoldLastFrameForSpeak>
      <FirstFrameUnderlay>false</FirstFrameUnderlay>
      <BackgroundSuppress>KimaEars.png</BackgroundSuppress>
      <Name>earsmove1</Name>
      <ZIndex>0</ZIndex>
    </Animation>
  </Animations>

The section starts with an <Animations> element, which can contain 0, 1 or more <Animation> elements. Each animation defines a series of ‘frames’, where a frame represents a single image in the animation. A frame contains a Duration section, an ImageResource and a VisemeGroupName. The last one, you can forget about, it’s there because of backward compatibility reasons with the original CCS file format and should always be empty (for now). We’ve already been over the ImageResource element and the duration simply declares how long that the image should be displayed. This is expressed in milliseconds.

Underneath the frames, you need to declare some more info about the animation. Besides the name of the animation, which is used to start the animation in a rule’s output patterns, you have:

EnableFrameSpeaking When true, speech is allowed during the animation. When false, speech will wait until the animation is done.
HoldLastFrameForSpeak Is currently not used and can be true or false.
FirstFrameUnderlay When true, the complete background is hidden and the first frame of the animation is used as background
BackgroundSuppress This element can be declared multiple times. Each element contains the name of a background image that needs to be hidden while the animation is running.
ZIndex Optionally determines the ZIndex at which the animation is displayed. This is useful to move parts in front or behind other parts. The background always has a ZIndex of 0.

It might seem a tremendous task at first to declare every frame in an animation like this. But it turns out that most animations can be build using between 3 and 7 images, sometimes reusing images to build sequences of about 10-20 frames. So all in all, this is still manageable.

VisemeGroups

The next section declares the images used for lip-syncing. The basic structure looks like the following xml snippet (note that it doesn’t contain an entry for all 22 viseme images, just the first 2).

  <VisemeGroups>
    <VisemeGroup>
      <Name>Default</Name>
      <ZIndex>1</ZIndex>
      <VisemeImages>
        <VisemeImage>
          <VisemeIndex>0</VisemeIndex>
          <ImageResource>images\Kima00.png</ImageResource>
        </VisemeImage>
        <VisemeImage>
          <VisemeIndex>1</VisemeIndex>
          <ImageResource>images\Visemes\Kima03 EH.png</ImageResource>
        </VisemeImage>
      </VisemeImages>
    </VisemeGroup>
  </VisemeGroups>

The file format already allows for multiple viseme groups to be declared, although at the time of writing, only the first one is used (and supported). Multiple viseme groups could be useful for moving heads: a viseme group for each head position.  As such, the ‘name’ element for each group would be used to reference a group. But, as already mentioned, this is something for the future. 

The ZIndex element defines the Z-order that should be applied to the viseme images. This allows you to manipulate the order of the images. For instance, you could use this to move a part of the background image on top of the viseme images.

Next comes the ‘VisemeImages’ group, with a ‘VisemeImage’ for each mouth position + optionally 1 extra image for the silence position.  Each VisemeImage contains an ImageResource (as described above) and an Index (VisemeIndex), which determines the letter that the image represents (so the order in which the VisemeImages are declared, is irrelevant).

The silence is primarily for backward compatibility with verbot characters (which don’t have a separate background section). If you have a ‘Background’ section, the viseme image at index 0, will be skipped, otherwise it’s used as the background. That’s why the ‘background’ section has to be declared before the VisemeGroups.

IdleLevels

Idle time is the time when a bot doesn’t have anything to say or any emotion to show. In other words, nothing’s happening. In order to create the illusion of being alive during this period, you can use idle levels to start animations (that were declared in the ‘Animations’ section) when the bot is idle. Here’s the definition:

  <IdleLevels>
    <IdleLevel>
      <MinStartDelay>5</MinStartDelay>
      <MaxStartDelay>15</MaxStartDelay>
      <MinDuration>5</MinDuration>
      <MaxDuration>15</MaxDuration>
      <MinInterval>2</MinInterval>
      <MaxInterval>8</MaxInterval>
      <AnimationNames>
        <AnimationName>earsmove1</AnimationName>
        <AnimationName>eyes squint</AnimationName> 
      </AnimationNames>
    </IdleLevel>
  </IdleLevels>

Like most other sections, you can again declare multiple IdleLevels. In this example, we only have 1 though. The idea behind multiple IdleLevels is this: when the idle time starts, the first idle level is activated, but when the duration of the level has ended, the next one is activated until the last one is reached, which remains running until some activity happens. This way, you can have a bot act differently after x amount of idle time, progressively.

Each idle level contains 4 bits of information: 3 time ranges and a list of animation-names that the idle level can use. Each range has a Min and Max component, indicating the lower and upper part of the range. The different times are used for:

Delay A value is selected at random from this range to delay the start of the animation (which is otherwise immediately after the last output)
Duration A value is selected from this range to determine the duration of the idle level. This is only used if the level isn’t the last in the list.
Interval Each time an animation finishes, a value is selected from this range to determine how long the system should wait before it starts another animation from the list (this is selected at random).

BackgroundAnimations

Idle levels are very useful to create a sense of liveliness, but they can be expanded upon. Sometimes, it’s also useful to have animations run all the time in the background, even while speaking. A good example of this could be breathing or eye blinking. For this purpose, there is the final section, called ‘BackgroundAnimations’, which contains a series of special animation definitions, all of which will run all the time, in a loop. Here’s the definition:

  <BackgroundAnimations>
    <Animation>
      <AnimationFrames>
        <AnimationFrame>
          <Duration>10</Duration>
          <ImageResource>images\other\Kima Nose Flare (01).png</ImageResource>
          <VisemeGroupName/>
        </AnimationFrame>
        <AnimationFrame>
          <Duration>10</Duration>
          <ImageResource>images\other\Kima Nose Flare (02).png</ImageResource>
          <VisemeGroupName />
        </AnimationFrame>
      </AnimationFrames>
      <Name>nosebreath</Name>
      <LoopStyle>VarTimer</LoopStyle>
      <MinStartDelay>1</MinStartDelay>
      <MaxStartDelay>3</MaxStartDelay>
      <ZIndex>2</ZIndex>
    </Animation>   
  </BackgroundAnimations>

Unlike idle levels, the animation is declared inline this time.  That’s because there is a small difference in declaration between this type and idle/emotion animations. Another reason is to make certain that background animations can’t be used as emotions (they run all the time anyway, no need to start them separately).

The way that the individual frames are declared is the same as with regular animations: a list of ‘AnimationFrame’ objects that define the image, the duration and an optional viseme group. The difference is in the extra options: there is an extra ‘LoopStyle’ and ‘StartDelay’ range. ZIndex is also the same as in animations: It determines the Z-Order at which the animation is displayed, the higher the number, the more to the top it will be.

The ‘StartDelay’ range is used to build in a small idle time between each animation loop. Each time that the animation needs to be started, a value is selected at random from within the range. That’s the delay which will be used. Not every loop-style makes use  of this delay, some do, others skip it.

Finally, the LoopStyle element can have the following values:

None The least useful: no looping at all.
Jojo At each start, the end frame is selected at random from the entire list of frames. When this end is reached, the animation is played in reverse until the first frame is reached and the loop starts again.  Each start is delayed by x amount of time, where x is a random number picked from the StartDelay range.
FrontToBack The images is played continuously, front to back without pauses.
VarTimer The images is played front to back in loop, but each time with a delay that is selected from the StartDelay range.

And that’s it. Once you’ve got all these sections laid down, you’ve got yourself a character. All that remains, is to copy the files to the {my documents}\NND\Characters dir and restart the chatbot designer. Enjoy.

 Posted by at 16:48  Tagged with: , ,

The different file types

 Documentation  No Responses »
Oct 242011
 

The chatbot designer uses a number of different file types to accomplish different tasks. Here’s a short overview of all possible files (and sometimes directories):

Projects

A project contains the entire neural network (in binary form) together with a bunch of configuration files in a directory. This directory is accompanied by the main project file. Both have the same name.  When moving around a project, make certain you have both file and directory. When opening and saving projects, you only need to worry about the file, the directory will be created/managed automatically (done in such a way that extra directories like for version control systems, will remain functioning).
The project files themselves (extension ‘.dpl’), are simple xml files which contain various configuration data for the designer. In general though, you don’t need to edit this file manually, all settings can be managed from within the designer.
The most important files in the project directory are binary and should never be manually edited. Some files are xml based, but apart from the test-cases, should be left ‘as-is’ since they contain vital configurations for the internal network.

Topic files

Topics form a major component of a chatbot designer project. They define what the bot can do. Internally, topics are stored as neurons, but in order to share a topic across multiple projects and users, Topic files were introduced. This is an xml file (extension ‘topic.xml’) that contains all the rules defined in the project.

The designer provides functionality to import and export topics one by one or in bulk from the File menu or the context menu on the Project tool-window. So ideally, you should never be confronted with the internals of these files. For the die-hard text-editor fans, here’s a little more details on the structure:

A minimal topic file should contain a topic, name, rules and questions sections. Like:

<Topic>
  <Name>Who has</Name>
  <Rules />
  <Questions />
</Topic>

And a bit more challenging, containing a single rule with 1 input and output pattern pattern:

<Topic>
  <Name>Time</Name>
  <Rules>
    <Rule>
      <Name>new rule 1</Name>
      <Patterns>
        <Pattern>
          <Expression>What time is it [?]</Expression>
        </Pattern>
      </Patterns>
      <Conditionals />
      <Outputs>
        <Output>
          <Expression>It is $time:hour\:$time:minute\.</Expression>
          <QuestionCanFollow>True</QuestionCanFollow>
        </Output>
      </Outputs>
      <IsOutputSequenced />
      <DoPatterns />
      <Calculate />
  </Rules>
  <Questions />
</Topic>

For the curious, the expression: $time:hour\:$time:minute\.  is used to render something like 17:30. The expression has to be split up in 4 parts:

time:hour returns the hour
\: we need to escape the : cause it is just after a variable path. If we don’t do this, the parser thinks that we will specify another function call.
time:minute returns the minute part of the time value.
\. The . also needs to be escaped, otherwise the parser thinks we are trying to further specify the path.

Global patterns

In the ‘chatbot properties’ view (From the menu: View/chatbot properties), you can specify a bunch of global patterns like the opening statements, fallback values, ‘do-patterns’ that need to be executed at startup, just after each statement,…  This also includes all the OS function-mappings that were declared in the ‘OS channel’.  All these can be exported/imported using 1 file, with the extension ‘global.xml’. Import/export can be done from the menu: ‘file/import/global patterns’ or ‘file/export/global patterns’. 

As you probably already guessed, this is also in xml format, but like with the topics, the content can be fully managed from within the designer, so there is no need to edit it manually.

Thesaurus files

Thesaurus files are used to share, exchange or replace part of, or the entire thesaurus that is used in a single project (thesauri are project specific and not shared across different projects within the designer). It’s the same routine again as for the previous file types: the extension is ‘thesaurus.xml’, yes, it’s an xml file format and can be fully managed from within the designer. In fact, for the thesaurus, it is more than advised to use the designer and not edit it manually since a thesaurus node can be hard to define as there are multiple levels at which words are stored. The only scenario where you might have to do some manual editing, is when you create a new thesaurus, completely from scratch when all the functionality needs to be preserved and you don’t have access to a network-designer version of the chatbot designer. In that case, the ‘bindings’ section on certain words (numbers, pronouns like I, me, myself,.. needs to be done manually. Here’s a small example of a binding for the object ‘myself’:

  <Object Name="myself">
    <Text Value="myself" Index="0" POSGRP="false" />
    <Bindings>
      <ref>I</ref>
      <ref>Singular</ref>
    </Bindings>
  </Object>

Importing/exporting is done from the context menu on the thesaurus. If no node is selected, the entire thesaurus will be exported, or the content of the imported file will be added to the root. If a node is selected during an import operation, all items will be added as a child of the selected node. For export, only the selected item and all it’s children will be exported recursively.

It’s also possible to import or export just a single level of children of a selected node, in the form of comma-separated-value (csv) files.  For imports, you don’t even need to get the data from a file, but you can just as easily use the clipboard: just copy a csv list to the clipboard, go to the context menu of the parent node and select ‘Import\wordlist from clipboard’. This feature allows you to quickly build up trees of related words.

Asset files

Assets store concrete information like ‘you are reading this now’ and ‘I have written this text’. By now, the theme should have become clear to you: asset files are stored in the xml format, they have the extension ‘asset.xml’. But here’s where we stray a little from the path: currently asset import/export is only supported in the pro version (that is, it’s still a little bit under construction, so it will soon be available). The same for editing: the pro will have an asset editor, but not the basic version. The latter only has the chatbot window for adding input statements.

Test cases

Test case files aren’t independent files like ‘topic thesaurus, asset or global patterns’ files, but are rather part of the project directory. As such, you can’t currently export or import them automatically from within the designer (though you can fully manage them as in copy, delete, edit,.. from within the designer). That said, they do deserve a special mention since it could sometimes be useful to extract some test-cases and copy them to other projects. And, because a test-case file is actually a stand-alone xml file, this is certainly possible.

Test case files are located at {project directory}\DesignerData\  and have the extension ‘TESTCASE’. If you copy a test-case from one project to another, or you want to delete some manually, make certain that the project is closed.

CCS files (characters)

As a final file format, I’d like to talk a little about characters and their files. A character is stored as an xml file (extension ccs) together with a bunch of images. These images can be located in a subdirectory of the ccs file, as long as the path can be described, relative to the ccs file.

For the chatbot designer to be able to use a character, the files (and possibly directory structure) of the char need to be copied to the directory: {My documents}\NND\Characters\CharName,  where ‘Charname’ is the name of the character. Best to do this when the chatbot designer isn’t running.

Unfortunately, ccs files can’t yet be edited in the designer (or any other UI tool). They need to be created manually. Luckily, the structure is relatively simple and allows for lots of copy/paste. More info on the file structure will come shortly.

 Posted by at 15:50  Tagged with: , , , , , , ,

Mika

 characters, chatbot designer, Screencasts  2 Responses »
Aug 112011
 

Check out the new character, called ‘Mika’:

Pretty cool He!. I think so as well. The character is another of Laticis Imagery’s creations. Ady provided all the images and I assembled them into a single character. The video demonstrates all the available expressions, which can be activated in the output using ‘mark’ ssml tags.

Perhaps some more information on the project: The first release, the basic version should be ready in a short while now, when I have created some content (which should also be a perfect opportunity to work out some of the final details). The basic edition will be a free (as in beer) version. After that, the pro will be prepared for release which will contain some more functionality like user interface automation, and/or home automation (not certain yet what to do first).

Some of the features that will be available in the first release:

  • Select if the bot starts the conversation or waits for some input on startup. Opening statements can be declared in the bot’s properties page.
  • You can declare custom memory operations that need to be performed each time the bot starts.
  • ‘Do patterns’ are also executed each time output was generated.
  • Input repetition is recognized (stored in memory as a counter) and can be handled with custom, conditional output patterns.
  • When no patterns matched, the system will use one of the custom fallback outputs.
  • Input patterns are grouped together into a single rule. These patterns share the same set of possible output patterns.
  • Multiple output patterns can be declared for a single rule. You can select if a random item needs to be selected from the list or if each item needs to be used in sequence (useful for story telling bots).
  • Each rule can have it’s own do patterns, which are used to manipulate the memory.
  • Rules are grouped together in topics (the 2 files that are imported in the video, each represent a topic), which are responsible for providing context. This allows you to declare the same pattern in multiple topics (useful for short statements like ‘why, when, yes, no,…’
  • Additional context can be added through do patterns and can be queried in conditions.
  • It’s possible to declare conditional questions at the level of a topic, meaning that multiple output patterns can share the same questions. The first one who’s condition matches will be used for outputs that don’t declare their own question.
  • A single output pattern can link to other output patterns, indicating that It should be used if the rule it belongs too, is the answer to a question declared in one of the linked outputs. This is useful to properly handle responses or when the user doesn’t respond as expected.
  • Time and date are supported in the output and conditionals through a variable. When used in combination with the thesaurus, some pretty powerful things can be done.
  • Test-cases for running automated tests on your bot.
  • Synonyms are automatically resolved in the input. This is a very powerful feature that’s able to recognize and replace compound words in the input. For instance,  if an input pattern contains ‘what is’ and the system knows the synonyms for ‘what is’ are ‘whats, what’s, wats, wat is, wat’s’, then you only need to declare 1 input pattern to recognize all of the possible synonyms.
  • Synonyms can be managed from the thesaurus editor.
  • The following operators can be used in the input patterns:
    • () group input together
    • [] option: words between the brackets are optional, not required to be present in the input
    • {} loop: words between the brackets can be found 0, 1 or more times (useful for lists)
    • | choice: the input needs to contain either the left part or the right part of the choice. This can be combined with an option, group or choice, like: [I | you | he | she | we | they]
    • $name: variable declaration: collects words that can be used in the output or conditions.
    • ^path: thesaurus variable declaration: the input needs to contain a word (or compound) that is a child of the specified thesaurus path (very powerful). The actual collected word can be used in the output/conditions like a regular variable.
    • && the and operator allows you to declare groups of words that need to be present in the input, but which can have ‘holes’ in between them, ex: (hello) && (what’s your name)
  • conditions and outputs can also use:
    • #path: declares a data-path into the memory.
    • ~name: to reference topics.
  • There is a built in topic-editor or you can edit them directly in xml format.
  • The built-in topic editor has a spell checker.
  • Patterns with errors have a red line, making them easy to find. The error text can be seen as a tooltip or in the log.
  • …
 Posted by at 18:55  Tagged with: , , ,

Presenting chatbot designer

 chatbot designer, General, Updates  No Responses »
Jul 022011
 

For those who  have  been wondering what the bleep I have been up to for the past few months, well check out the video:

Looks pretty cool he? So, what happened? Well in short, I took the neural network designer, removed everything complicated from view that remotely had anything to do with ‘neurons’ but kept all the memory functionality, added a character engine and a simple but powerful pattern matcher (implemented in neural code, pretty cool I think,… and simple stuff).

The character in this demo (actually called Tara – and still in development) is designed and named by Ady Di Pierro from Laticis Imagery.  The drawings were made with DAZ3 and assembled in something very similar to verbot’s CCS file.  In fact, all verbot characters should work in this character engine as well, cause I only added features to the file format but didn’t change any existing.    The images were manually assembled for this character cause there is no char-editor yet.  That is scheduled.

Also check out what Roger Davie (aka Freddy, Admin of the AI  dreams forum) did with the forum’s bot:

The images are also rendered with DAZ. He definitely has the visemes already worked out better than in the first demo.

So, how did all of this come to be, you might wonder. Well, I think you can thank Wendell Cowart from the chatterbox challenge for this. He originally contacted me with a request for a new ‘pattern based’ chatbot project. I took this as a nice challenge to demonstrate exactly just how flexible resonating neural networks are. Soon, Patti Roberts of Bildgesmythe also joined in. Together, they basically told me how they would like to have things, which features they were looking for and such. Thus, this little project was able to come into existence at record speed.
Patti and Wendell also helped out a lot with the initial ‘mid development’ testing, which I’m sure you understand is a pretty frustrating job to do, as things are usually not yet behaving the way they are expected to. So many thanks for cracking out those basic ‘issues’.

Anyway, for those who would like to play with it for themselves, a first public beta release will most likely be coming shortly. Just keep in mind that any first release will be a ‘technology preview’ sort of say.

 Posted by at 17:32  Tagged with: , ,
© 2012 Neural Network Design blog Suffusion theme by Sayontan Sinha