Jump to content

Learning Material to write an exporter ?


Recommended Posts

Hi Guys !

 

I have check those 2 threads :

http://forums.odforce.net/topic/6069-how-to-write-exporters/?hl=%2Bgeometry+%2Bexporter

http://forums.odforce.net/topic/5806-easiest-way-to-write-geometry-to-a-file/?hl=%2Bgeometry+%2Bexporter#entry39069

 

But i would need an exemple source code of a Basic geo exporter for ex :

- poly geometry exporter

- curves exporter

- particles / sprites exporter

Where can i find a simple / concise code for this ?

 

My C++ is rusty , My C skill are pretty find. If a full C solution exist it would be great , if i need to dive in the C++ mess thats ok ... :)

 

My goal is pretty basic i want to write

- a ROP outpout driver

- geometry loader

 

That allow me to export / load Three.js compatible JSON assets

https://github.com/mrdoob/three.js/wiki/JSON-Object-Scene-format-4

 

If would like to have an ASCII and a BINARY exporter.

If you have any suggestion about the best compression algorithm it would be very useful.

 

Well thanks for any input / advise / feedback that could help me in this task ... :)

 

Cheers

 

E

Edited by sebkaine
Link to comment
Share on other sites

I would go with Python version at least for start. You have working examples here:

http://forums.odforce.net/topic/19535-inline-cpp-pc2-exporter

I presume Webgl assets will be lightweight anyway and Python can be really fast by using floats arrays as strings as explained above (not iteration over points).

 

When it comes to HDK ROP_Dumper.C example is fair enough. GEO_Detail and GU_Detail are probably all you need to access geometry and write it on disk. There are also open source projects like krakatoa or realflow exporters somewhere around as good reference:

https://github.com/ThinkboxSoftware/HoudiniPRTExporter

  • Like 1
Link to comment
Share on other sites

Many thanks for your (always!) very helpful answers SYmek ! :)

 

That's exactly what i need ... Python to warm the brain, then C++ if i need more speed.

 

I have very few experience with Python in H as i am more using VEX as much as i can (i love VEX :wub: ).

I would be curious to understand how things works compare to Maya.

 

In Maya

- you can access the scripting commands (MEL) with a Python binding call with maya.cmds.

- you can access the core API (C++) with a Python binding call with maya.OpenMaya

 

I would be curious to understand how things works precisly for Houdini and the HOU module.

- basically the original scripting commands are in Hscript, does HOU behave as a binding or as a full replacement ?

- the core HDK is in C++ in H, do you have a Python biding that give you access to the full HDK function in the HOU module ?

 

To sum up does HOU give access to scripting + HDK API ? in this case HOU would be the equivalent of Pymel (= 2 different world access in one language)?

The only difference could be that Python scripting is not a Hscript binding ?

 

Sorry if my post is kinda confuse, but if Python give me access to all the Houdini function , i think i will try to save myself some precious neurone breaking

and stay away from the C++ mess ...

 

Cheers

 

E

Edited by sebkaine
Link to comment
Share on other sites

I would be curious to understand how things works precisly for Houdini and the HOU module.

- basically the original scripting commands are in Hscript, does HOU behave as a binding or as a full replacement ?

 

HOM (Houdini Object Model) is complete API with Python bindings (hou module) which can fully replace hscript. It's a new, built from ground up API designed to access Houdini internals, so it hasn't much in common with old hscript or expressions (which meant to be replaced too, but thankfully are still around).

 

- the core HDK is in C++ in H, do you have a Python biding that give you access to the full HDK function in the HOU module ?

 

Nope, that's Maya thing. It's possible thanks to Maya API which is small and encapsulated enough to be used by third parties with minimal effort. HDK is much more than that and less at the same time. Since these are basically the same headers as used by developers, it wouldn't be visible to bind it with Python. You have an access to almost everything, for a price though :)

 

The only difference could be that Python scripting is not a Hscript binding ?

 

Hscript is like bash in Linux. It manipulates nodes and parameters. It's hardly used these days. Hscript Expressions on the other hand are functions evaluating on geometry and other entities. They do well their work in parameters, but these days VEXpressions and Python are more and more preferable I suppose.

 

Sorry if my post is kinda confuse, but if Python give me access to all the Houdini function , i think i will try to save myself some precious neurone breaking

and stay away from the C++ mess ...

 

 

Python gives you access to all Houdini geometry, nodes, and networks but it doesn't contain all SOPs functionality (like there is no 'scatter' command in python unless you make it your self - you cannot process geometry in Python with the same operators like in SOPs), but you can write PythonSOP, which will evaluate and modify geometry with your own functions and most importantly from your point of view, Python can export jsons with all geometry data (outside PythonSOP access to read-only).

  • Like 1
Link to comment
Share on other sites

Many thanks for all those precious info SYmek !

 

So SESI did it the clean way, Python API is standalone and extendable.

If you want full HDK access , you have no shortcuts you have to pay the C++ price.

 

So i guess a clean custom tool creation protocol in H would be this one :

 

1 - If it can be done in VEX(VOP) do it in VEX => Ultra Fast / Simple

2 - if you encounter VEX limitation then do it in Python HOM => No so Fast / Simple

3 - if you want more speed try inline cpp inside Python to fasten the slow parts = > Fast / No so complex

4 - Then if you have burn 1,2,3 and still need a solution , take a deep breath and dive in C++ HDK => Ultra Fast / Hard

 

I generally stop 99% of the time at step 1 ... :)

 

Thanks again for the enlightment !

 

Cheers

 

E

Edited by sebkaine
Link to comment
Share on other sites

Many thanks for all those precious info SYmek !

 

So SESI did it the clean way, Python API is standalone and extendable.

If you want full HDK access , you have no shortcuts you have to pay the C++ price.

 

So i guess a clean custom tool creation protocol in H would be this one :

 

1 - If it can be done in VEX(VOP) do it in VEX => Ultra Fast / Simple

2 - if you encounter VEX limitation then do it in Python HOM => No so Fast / Simple

3 - if you want more speed try inline cpp inside Python to fasten the slow parts = > Fast / No so complex

4 - Then if you have burn 1,2,3 and still need a solution , take a deep breath and dive in C++ HDK => Ultra Fast / Hard

 

I generally stop 99% of the time at step 1 ... :)

 

Thanks again for the enlightment !

 

Cheers

 

E

 

I usually go this way:

if (vex is good for my task):

    go with vex

else:

    prototype with Python then go with hdk

 

I skip inline CPP completely, because it's almost unusable most of the time. You can't easily share your tool, because other users required to install MS Visual Studio to compile it. Moreover, you can't delete(or even hide) python code after compilation, because inline cpp always checks source code for changes. So inline CPP is pain in the ass, better go with hdk right away.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...