frequently asked questions
What is meshpage.org?
- Meshpage is a mechanism to create 3d animations and sending them to your friends.
How does the site work?
- You download the builder tool
- Create your demonstration with the tool
- You get piece of c++-like code
- Then you can "create a mesh"
- After creation, you get URL link to the created product
What are the advantages in your approach?
- OpenGL based software-only solution, so no need to buy a camera
- File size is very small. The file size is like 30 lines of c++ code,
instead of megabytes of video files
- It's based on "designing" 3d animations, instead of "recording" those animations
- End result can be sent via email to other people
What are the disadvantages?
- Work amounts are higher than simply pressing "record" button in a camera.
- Designing 3d animations usually requires some planning
- The tool is slightly more complicated than we wanted
- Flexibility of the underlying software is always a problem
- End product sizes are pretty small, so you can't expect full length movie
as the output of this process
- Different animation models are very limited -- basically just translate/rotate
- We don't have sound or music support at all, because it's fundamentally based on recording industry technology, and we're not experts in that area.
How is this different from other user-generated-content sites?
- There's isn't any issues with copyrights -- i.e. no DCMA kind of problems (this is necessary because it must work in EU)
- All content for the site must be created with the builder tool
- The tool can control what content is allowed to be included to the product, thus we can check against copyright infringements
- Bm_url and FI_load are the biggest features in this area.
- If we don't like some content, we can "hide" it from the front page, but
the urls still continue to work
How does meshpage.org get licenses to user's content?
- User still needs to agree to license the content he created with the tool
to meshpage.org and associates
- This is similar to how Youtube handles it, i.e. when user presses "Save & Publish" button on the web page, we get a license to display the content on our web page - before that, it'll only be displayed for that same user who is posting the content
- This is basically "implicit licensing".
- But current situation is that users are spending much less time creating content than what it took to create the GameApi library and GameApi Builder tool, so it can still be considered exchange of licenses -- user can use the builder tool in exchange of giving license to the content created with the tool.
- However we're still checking how LGPL license that we've chosen for the library will deal with the exchange requirement used in the site
What other problems are you seeing currently?
- Large problem in today's technologies is something called "Effort calculation".
- Effort calculation is based on the premise that web site authors are eating significant amount of time from their user base, but cannot even say critical questions like:
This kind of basic information is usually missing, and "Effort Calculation" is the key metric how it should be handled.
- how much time they're eating from their user base?
- how many people are using their site?
- how they can ensure that work amounts imposed to the user base are staying within acceptable range?
- what actions are taken, if work amount explodes and people are doing too much work to improve the user-generated-content-site?
How do bm_url and FI_load work?
You might notice that bm_url and FI_load are refusing to load some
urls which are not around the user's homepage.
We have some technology included that checks against user's copyright
infringements, before posting the content to meshpage.org. This is
implemented in the bm_url and FI_load features. Basically we use user's
homepage as a center of user's world, and implement a domain
restriction which limits usage of content inside meshpage.org
animations. For example when it loads png image from some url, it
checks whether the user's homepage was in the same domain.
The theory behind this check is that we should allow only content that
user published himself, instead of all the content in the world, and
thus domain where user's homepage is at, is good candidate for allowed
content. This cannot provide absolute guarantee against copyright
infringements, but it prevents certain kind of spread pattern where
user picks urls from all around the world and uses them as content
inside the animations. Since meshpage.org is publishing this content
in the web page, we try to check problems in the content.
This domain restriction check is more cunning that you'd expect, since if
you use several pieces of content in an animation, they need to all come from
the same domain. I.e. you can't pick one url from one domain and next url from
completely different place. Expectation is that animations contain more than
one piece of content/sprites/bitmaps/fonts/etc.., and thus the domain restriction can pinpoint the location of the user's real homepage address.
Other features than bm_url and FI_load cannot use external content at
all, so all content coming from other features are built competely
using GameApi Builder tool. This ensures pretty much that the user
created it himself, at least if copy-pasting CodeGen output code snippets
are not counted.
Note that currently we do not have login system for end users
implemented, so the domain check is per individual animation. Once
login system gets improved, it would allow implementing the domain
check for per-user homepage, instead of per-animation homepage. This
would improve the system, but is not currently implemented.
What features have domain check like bm_url & FI_load
- fi_load / load_font
This means these can load asyncronously data from url's and that
loading is handled via domain restriction.
Why builder can't load textures via p_mtl?
- it can, but you need to use p_mtl and m_texture_many_p together.
What technologies are you using to provide the features of the site?
- (normal browser environment)
In addition to these external stuff, we have internal development in the following modules:
- GameApi Builder/editor
What kind of features are available in the base system?
- OpenGL instancing
- 3d mesh data structure
- colours/normals/texture coordinates
- materials like snow/brashmeta/web/distance fields
- skeletal animations
- vertex animations
- recursive shapes/trees
- 2d and 3d rendering
- sprites / bitmaps
- circles/rectangles/triangles in 2d
- fonts/text rendering
Why do tool menus not do anything?
- you can link boxes whenever the labels match
- display menu from right mouse button is disabled until linking has been completely done from the left side of the boxes -- this is because left side is inputs, and right side is outputs, and all inputs need to be available for box to work correctly
What keybindings are there in the tool?
- ctrl-s saves the data to mod.txt
- 'a' rotates the model in most dialogs under "display"
- 'd' rotates the model in most dialogs under "display"
- delete (in box title bar) deletes the box
- esc exits the application
- esc (in blk_window) exits the full screen mode
What tools you should try immediately?
- m_snow, m_flat for shading
- anim_translate/anim_rotate for movement
- move_ml for movement
- seq_ml for moving from one scene to another
- cube/sphere/cone/torus for basic shapes
- p_render/m_bind for basic rendering
- p_render_inst/m_bind_inst for OpenGL instancing
- li_from_polygon/li_to_cone/random_quad for some amazing effects
- static_instancing/ms_static_inst for cpu side instancing
- blk_window and MainLoopApi features to finish your product
© 2013-2018 Tero Pulkkinen