Giter Site home page Giter Site logo

pixaranimationstudios / opensubdiv Goto Github PK

View Code? Open in Web Editor NEW
2.8K 306.0 556.0 67.12 MB

An Open-Source subdivision surface library.

Home Page: graphics.pixar.com/opensubdiv

License: Other

Python 0.64% C++ 76.15% C 13.28% Makefile 0.02% Cuda 0.21% CMake 2.14% GLSL 1.82% HLSL 1.58% Objective-C 1.57% Objective-C++ 0.57% Metal 2.02%

opensubdiv's Introduction

OpenSubdiv

OpenSubdiv is a set of open source libraries that implement high performance subdivision surface (subdiv) evaluation on massively parallel CPU and GPU architectures. This codepath is optimized for drawing deforming subdivs with static topology at interactive framerates. The resulting limit surface matches Pixar's Renderman to numerical precision.

OpenSubdiv is covered by the Apache license, and is free to use for commercial or non-commercial use. This is the same code that Pixar uses internally for animated film production. Our intent is to encourage high performance accurate subdiv drawing by giving away the "good stuff".

Feel free to use it and let us know what you think.

For more details about OpenSubdiv, see Pixar Graphics Technologies.

Linux Windows macOS
dev Build Status Build Status Build Status
release Build Status Build Status Build Status

Documents

Forum

Prerequisite

For complete information, please refer OpenSubdiv documents: Building with CMake

  • General requirements:
Lib Min Version Note
CMake 3.12 Required
  • Osd optional requirements:
Lib Min Version Note
CUDA 4.0 cuda backend
TBB 2018 TBB backend
OpenCL 1.1 CL backend
DX11 SDK DX backend
Metal 1.2 Metal backend
  • Requirements for building optional examples:
Lib Min Version Note
GLFW 3.0.0 GL examples
Ptex 2.0 ptex viewers
Zlib (required for Ptex under windows)
  • Requirements for building documentation:
Lib
Docutils
Doxygen
Graphviz

Build example to run glViewer and other example programs with minimal dependency

All platforms:

  • Install cmake and GLFW

make sure GLFW install directories are configured as follows:

   ${GLFW_LOCATION}/include/GLFW/glfw3.h
   ${GLFW_LOCATION}/lib/libglfw3.a (linux)
   ${GLFW_LOCATION}/lib/glfw3.lib (windows)
  • Clone OpenSubdiv repository, and create a build directory.
   git clone https://github.com/PixarAnimationStudios/OpenSubdiv
   mkdir build
   cd build

Windows (Visual Studio)

cmake ^
    -G "Visual Studio 15 2017 Win64" ^
    -D NO_PTEX=1 -D NO_DOC=1 ^
    -D NO_OMP=1 -D NO_TBB=1 -D NO_CUDA=1 -D NO_OPENCL=1 -D NO_CLEW=1 ^
    -D "GLFW_LOCATION=*YOUR GLFW INSTALL LOCATION*" ^
    ..

cmake --build . --config Release --target install

Linux

cmake -D NO_PTEX=1 -D NO_DOC=1 \
      -D NO_OMP=1 -D NO_TBB=1 -D NO_CUDA=1 -D NO_OPENCL=1 -D NO_CLEW=1 \
      -D GLFW_LOCATION="*YOUR GLFW INSTALL LOCATION*" \
      ..

cmake --build . --config Release --target install

macOS

cmake -G Xcode -D NO_PTEX=1 -D NO_DOC=1 \
      -D NO_OMP=1 -D NO_TBB=1 -D NO_CUDA=1 -D NO_OPENCL=1 -D NO_CLEW=1 \
      -D GLFW_LOCATION="*YOUR GLFW INSTALL LOCATION*" \
      ..

cmake --build . --config Release --target install

iOS

SDKROOT=$(xcrun --sdk iphoneos --show-sdk-path) cmake -D NO_PTEX=1 -D NO_DOC=1 \
      -D NO_OMP=1 -D NO_TBB=1 -D NO_CUDA=1 -D NO_OPENCL=1 -D NO_CLEW=1 \
      -D CMAKE_TOOLCHAIN_FILE=../cmake/iOSToolchain.cmake -G Xcode \
      ..
  • This will produce an "OpenSubdiv.xcodeproj" that can be open and the targets 'mtlViewer' and 'mtlPtexViewer' (if NO_PTEX is ommitted and libPtex.a is installed in the iOS SDK) that can be run

Useful cmake options and environment variables

-DCMAKE_BUILD_TYPE=[Debug|Release]

-DCMAKE_INSTALL_PREFIX=[base path to install OpenSubdiv]
-DCMAKE_LIBDIR_BASE=[library directory basename (default: lib)]
-DCMAKE_TOOLCHAIN_FILE=[toolchain file for crossplatform builds]

-DCUDA_TOOLKIT_ROOT_DIR=[path to CUDA Toolkit]
-DOSD_CUDA_NVCC_FLAGS=[CUDA options, e.g. --gpu-architecture]

-DPTEX_LOCATION=[path to Ptex]
-DGLFW_LOCATION=[path to GLFW]
-DSTRINGIFY_LOCATION=[path to stringify utility]

-DNO_LIB=1        // disable the opensubdiv libs build (caveat emptor)
-DNO_EXAMPLES=1   // disable examples build
-DNO_TUTORIALS=1  // disable tutorials build
-DNO_REGRESSION=1 // disable regression tests build
-DNO_PTEX=1       // disable PTex support
-DNO_DOC=1        // disable documentation build
-DNO_OMP=1        // disable OpenMP
-DNO_TBB=1        // disable TBB
-DNO_CUDA=1       // disable CUDA
-DNO_OPENCL=1     // disable OpenCL
-DNO_OPENGL=1     // disable OpenGL
-DNO_CLEW=1       // disable CLEW wrapper library
-DNO_METAL=1      // disable Metal

opensubdiv's People

Contributors

andrewkww avatar aras-p avatar asluk avatar barfowl avatar c64kernal avatar davidgyu avatar davvid avatar dazcjones avatar dcclyde avatar gelder avatar githubhackerdavid avatar grhp avatar hsdk avatar ielillo avatar jcowles avatar jdemouth avatar levork avatar manuelknvda avatar nathan-at-digitalfish avatar nathanlitkert avatar nyue avatar pixeljetstream avatar poljere avatar prideout avatar sergeyvfx avatar shengfuintel avatar significant-bit avatar takahito-tejima avatar theblackunknown avatar thomthom avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

opensubdiv's Issues

Osd needs better compute kernel API

Currently API clients have to manually register the compute kernels, which may or may not have been included in the library because of missing system dependencies at the time osd was built.

A better approach would be to have Osd provide a list of available compute kernels (CPU / OMP / GLSL / CL / CUDA) and let the client code select from that blessed list instead.

One consequence of this would be a dynamic generation of the kernel menu in the glutViewer example.

Support dynamic linking

Ideally we want both a static & dynamic build of libosd - and to link the example / regression code against the dynamic lib where possible.

Limit surface position, normal and du, dv at given s,t

Hi,

Does the library provide methods to find the point position, normal, du and dv at a given (s,t) on the limit surface ?

If it does, what are the methods called ? A quick glance at the code didn't reveal that.

If not, is this something that will be available in future ?

Regards

Using of unitialized variable PixarAnimationStudios-OpenSubdiv-e298d17/opensubdiv/hbr/creaseEdit.h

I found a potential usage of an unitialized variable in file PixarAnimationStudios-OpenSubdiv-e298d17/opensubdiv/hbr/creaseEdit.h at line 104.
The variable float sharp is declared at line 96 ( without initialization). Then an if - elseif - block is following . If no one of these if-elseif-blocks is executed, the variable sharp is used without intialization.

Here is the function i am referring to:

virtual void ApplyEditToFace(HbrFace<T>* face) {
    if (HbrHierarchicalEdit<T>::GetNSubfaces() == face->GetDepth()) {
        // Modify edge sharpness
        float sharp;
        if (op == HbrHierarchicalEdit<T>::Set) {
            sharp = sharpness;
        } else if (op == HbrHierarchicalEdit<T>::Add) {
            sharp = face->GetEdge(edgeid)->GetSharpness() + sharpness;
        } else if (op == HbrHierarchicalEdit<T>::Subtract) {
            sharp = face->GetEdge(edgeid)->GetSharpness() - sharpness;
        }
        if (sharp < HbrHalfedge<T>::k_Smooth) // <--- BOOM 
            sharp = HbrHalfedge<T>::k_Smooth;

.....

Best regards

Martin Ettl

glew link error on windows

FindGLEW finds glew lib for static lib (glew32s.lib) and DLL (glew.lib). If DLL is chosen here, -DGLEW_STATIC should not be defined in CMakeLists.txt. Otherwise link error occurs.

GLSL Catmark compute kernel

Produces incorrect results - check glutViewer to reproduce.

The bug was probably introduced when adding support for the bilinear subdivision scheme.

Make cmake build tolerant of missing modules

MSVC express apparently does not support OpenMP, which right now prevents almost everything from building : we need to isolate Osd's compute kernel dependencies and build with what is found.

Some feedback from cmake would also help guide users to enabling most features instead of just bombing out..

cuda kernel should be compiled with -fPIC in linux

getting this error when libosd is going to be linked to other dso

lib/libosd.a(osd_generated_cudaKernel.cu.o): relocation R_X86_64_32 against `computeFace(float_, int, float_, int, int_, int_, int, int, int)' can not be used when making a shared object; recompile with -fPIC

osd_regression crashes due to GL calls without any OpenGL context

Either we need to set up an OpenGL context for osd_regression or we need to not call glGenBuffers() etc in OsdMesh::Create().

I have a change that makes the test run again by setting up an OpenGL context, so if that is the correct solution I can create a pull request with that change.

Bug report for Mac compilation

Macbook Pro
OS: Mac OS X ver. 10.6.8

Compiling lib IlmBase 1.0.2:

localhost:ilmbase-1.0.2 laurenceemms$ ./configure
checking build system type... i686-apple-darwin10.8.0
checking host system type... i686-apple-darwin10.8.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for a BSD-compatible install... /usr/bin/install -c
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking dependency style of gcc... gcc3
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld
checking if the linker (/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) is GNU ld... no
checking for /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... myes
checking for unistd.h... ayes
checking dlfcn.h usability... kyes
checking dlfcn.h presence... eyes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 196608
checking command to parse /usr/bin/nm output from gcc object... rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
checking if gcc supports -fno-rtti -fno-exceptions... rm: conftest.dSYM: is a directory
no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... rm: conftest.dSYM: is a directory
yes
checking if gcc static flag -static works... rm: conftest.dSYM: is a directory
no
checking if gcc supports -c -o file.o... rm: conftest.dSYM: is a directory
yes
checking whether the gcc linker (/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin10.8.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
checking for ld used by g++... /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld
checking if the linker (/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) is GNU ld... no
checking whether the g++ linker (/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fno-common
checking if g++ PIC flag -fno-common works... rm: conftest.dSYM: is a directory
yes
checking if g++ static flag -static works... rm: conftest.dSYM: is a directory
no
checking if g++ supports -c -o file.o... rm: conftest.dSYM: is a directory
yes
checking whether the g++ linker (/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin10.8.0 dyld
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking whether make sets $(MAKE)... (cached) yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... -D_THREAD_SAFE
checking for cc_r... gcc
checking semaphore.h usability... yes
checking semaphore.h presence... yes
checking for semaphore.h... yes
checking for library containing sem_init... none required
checking whether to use POSIX unnamed semaphores... no (pshared not usable)
configure: multithread true, LIBS = , CC = gcc, CXXFLAGS = -g -O2 -D_THREAD_SAFE
checking for ANSI C header files... (cached) yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking for strerror... yes
checking for complete iomanip support in C++ standard library... yes
checking for gcc optimization flags... -pipe
configure: creating ./config.status
config.status: creating Makefile
config.status: creating IlmBase.pc
config.status: creating config/Makefile
config.status: creating Half/Makefile
config.status: creating HalfTest/Makefile
config.status: creating Iex/Makefile
config.status: creating IexTest/Makefile
config.status: creating IlmThread/Makefile
config.status: creating Imath/Makefile
config.status: creating ImathTest/Makefile
config.status: creating vc/Makefile
config.status: creating config/IlmBaseConfig.h
config.status: executing depfiles commands


Summary for IlmBase features:

OS X architectures default
OS X SDK default

OS X two-way universal build (deprecated) no

localhost:ilmbase-1.0.2 laurenceemms$ make
Making all in Half
if g++ -DHAVE_CONFIG_H -I. -I. -I../config -I../config -pipe -g -O2 -D_THREAD_SAFE -Wno-long-double -MT eLut.o -MD -MP -MF ".deps/eLut.Tpo" -c -o eLut.o eLut.cpp;
then mv -f ".deps/eLut.Tpo" ".deps/eLut.Po"; else rm -f ".deps/eLut.Tpo"; exit 1; fi
cc1plus: error: unrecognized command line option "-Wno-long-double"
make[1]: *** [eLut.o] Error 1
make: *** [all-recursive] Error 1
localhost:ilmbase-1.0.2 laurenceemms$ make
Making all in Half
if g++ -DHAVE_CONFIG_H -I. -I. -I../config -I../config -pipe -g -O2 -D_THREAD_SAFE -Wno-long-double -MT eLut.o -MD -MP -MF ".deps/eLut.Tpo" -c -o eLut.o eLut.cpp;
then mv -f ".deps/eLut.Tpo" ".deps/eLut.Po"; else rm -f ".deps/eLut.Tpo"; exit 1; fi
cc1plus: error: unrecognized command line option "-Wno-long-double"
make[1]: *** [eLut.o] Error 1
make: *** [all-recursive] Error 1

As a result I can't install OpenSubdiv on my Macbook Pro

Hbr needs a regression suite

With some early feedback trickling in, it is somewhat likely that Hbr might see some enhancements : we need a thorough regression data set to make sure that nothing gets broken accidentally.

Hbr improvements

Some suggestions from jcgagnon :

First, seems that all the code is in header files because you templated the precision of the vertex position; I think that makes things heavier for the compiler, and if the positions were stored in some generic attribute conatiner (like in Alembic), and were accessed through some interface instead of being embedded directly in the mesh structure, just like other attributes (UVs, normals, etc), it could help make the code cleaner. The position attribute could itself be templated by its precision, but a generic interface to access to it would avoid to template all the mesh and algorithms based on that. That generic interface could include calls such as processing some linear combination of attributes. And, position-related algorithms could be templated based on precision, but at least it would be localized.

Another thing is the choice, in hbr, to use pointers and instanciated classes (mesh, edge, vertex) directly as the stored structure. Although that might make things look more user-friendly, it makes everything take more memory and have more memory fragmentation. In particular, can no longer reallocate memory blocs and need to use that bloc allocator so your pointers remain valid (in which I would use more than 64 elements per blocs, which seems to be your default). To me, that is a bit like if std::vectors were implemented by storing an array of <iterator, data> pairs; it's a lot of redundancy that doesn't need to be always in memory. Instead, personally I prefer to store data in compact data structures, and instead use temporary iterators (or accessors) to add, when needed, the user friendly wrappers on top of it. For instance, the vertex data would be pure data, but the stack-allocated vertex accessor (or iterator) would wrap both the vertex index and the mesh pointer, and give all the required facilities (get adjacent faces, children faces, vertices, etc). And, using indices instead of pointers make the structure realloc-friendly, which is good since keeping the data in contiguous, big arrays avoids memory fragmentation, which is often biggest performance bottleneck when in polygon mesh data structures.

Remove IlmBase dependencies

We are only using IlmBase Mutex in Hbr and some minimal vector functions in the regression & example code.

The dependency however is causing a fair amount of build & deployment headaches, so I suggest that we simply implement this ourselves.

Osd regression needs to default to kCPU

OpenMP is not present in every compiler, so default Osd regression code to kCPU mode until we have something that tests automatically all the registered kernels.

fix incoming.

Fix GLEW includes in osd

GLEW should be removed from header files as it can conflict with other includes in client projects.

FarCatmarkSubdivisionTables crash

Creating the tables for regression shape "catmark_tent" with tag interpolateboundary set to 2 crashes the regression.

I tracked the problem to a faulty assumption that vertex-vertices always have an incident edge, which may not always be true (look for XXXX in the code).

Cleanup Hbr Mutex

The mutex implementation does not belong in the representation layers. Furthermore, since most large-scale client apps will have their own mutex implementation, we should allow them to use those instead.

OpenCL compile errors

Trying the glutViewer on OSX 10.8, I got few errors, which were trivial to fix.
in two places there was "if (not pass" which I changed to "if (!pass"
and M_PI was undefined, adding a definition for fixed that.
After fixing those, I was able to use the OpenCL kernel in glutViewer.

Hbr not in namespace

Currently Hbr is using some strategically placed #include in the middle of method implementation which prevent me from encapsulating the library in the OpenSubdiv namespace. Moving the #includes has proven tricky as there is a set of cyclic code dependencies and it's not obvious how to break it.

This should not be causing symbol tables problems, so it's more a cosmetic issue i guess.

HBR Speedup

Thought I'd create an issue to track options for HBR speedup. The way I see it there are several possibilities:

-Port HBR to the GPU: This is an interesting option but could be hard to implement due to dynamic memory operations.
-Multithread everything by hand: Could be tricky if there is a lot of communication which I suspect there is.
-Try Intel's TBB or Thrust on large loops: If we are compute bound, a lot of the loops could easily be multithreaded in place if we use TBB/Thrust depending on which turns out to be faster.

We should run profiling on the code to identify whether we're memory or compute bound. If we're memory bound, there's almost no point in moving to the GPU and we should explore a CPU threaded port. Ask Jiayi re: profilers or email me on Monday. We recently installed Intel's VTune Amplifier at the main office.

Far needs refactoring

Currently the design of Far with a dual-template is awkward and causing headaches for API clients as well as Osd.

I suggest :

  • moving all CPU compute kernel code into the Dispatcher
  • moving all Hbr traversal used in table creation outside of the subdivision / edits classes and into "factory" code
  • un-template all fundamental table classes because they do not need to know about the vertex class !

This gives :

  • meshFactory (and other Hbr traversing code) still dual templated <T,U=T> : it's OK, they are the glue between Hbr and Far and we still want the ability of specifying a different vertex specialization for each
  • dispatcher is templated on "U" only and provides reference implementation for all the compute kernels (this should simplify some of the indirection between the subdiv tables and the dispatcher anyway)
  • subdiv & edit tables are not templated at all.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.