LuxRender Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000614LuxRenderCorepublic2009-11-06 01:562012-09-11 09:11
Assigned ToLord Crc 
PlatformOSOS Version
Product Version 
Target Version1.0Fixed in Version1.0RC1 
Summary0000614: REQ: Check sum like function to avoid transfering the same data (network)
DescriptionI'd like to avoid transfer the same data over and over again. So lets say
I have a scene that is quite heavy poly wise and I'm setting up the scene.
Then even when I just change a material or other small setting, the whole
geometry gets transferred again and again. This is a big waste of network
resources and much more it's wasting my time. So please consider to introduce
some kinda check. If that's to hard to do, maybe introduce some switches that
let us decide what to transfer again. ie. material/geometry/settings
Of course the check sum would be better because it would avoid mistakes.
TagsNo tags attached.
Mercurial Changeset #cb3265a7cf69
Requires Documentation UpdateNo
Requires Exporter Update
Attached Files

- Relationships
related to 0001188new FLM files should have a unique identifier 

-  Notes
jeanphi (administrator)
2009-11-06 03:47

Currently the geometry isn't stored on the receiving computer, only external data files are stored (textures, nk files, ies files). The lux data is sent and immediately processed at the receiving end. Given the versatile nature of the lux input (file, but also standard input or even API), it'll be quite difficult to define the behaviour.
I do agree though that such a feature could save ressources.
Omniflux (developer)
2012-01-14 21:28

Currently textures are stored with a new filename and an incrementing number. It would be nice if the files were given a less volatile name such as a hash so if I have a queue of several scenes all using the same textures each texture would only have to be transferred once.
Lord Crc (administrator)
2012-01-14 23:08

We already use Boost.Uuid, so we could use it for this as well. We could generate a uuid based on the file name and file contents (which we read in anyway), and send this uuid. The slave could then reply if it has a file with matching uuid or if the master should continue the file transmission.
Omniflux (developer)
2012-01-15 14:30

Rather than waiting for a reply from the slave for each file, I would rather see the master send a list of all necessary files and then have the slave request the ones it needs.

This is only because I would eventually like to see the protocol support multicast.
Lord Crc (administrator)
2012-01-19 03:52

I think multicast will require a rather big change anyway, so going the easy route for now is preferable. If we implement 0000552 then I don't think it's a big issue that it's serial.
Lord Crc (administrator)
2012-01-19 05:42
edited on: 2012-01-19 05:44

Using Boost.Uuid for this may be impractical as it doesn't have any way to compute a Uuid from an iterator or stream. I'm looking into the Tiger hash which has a small and free PD implementation available, and which seems to be pretty fast.

Computing the hash from the stream would be essential for sending files in parallel as loading multiple copies of large files into memory may exhaust master's available memory.

Lord Crc (administrator)
2012-05-10 22:00

I've pushed an initial implementation of this, see changeset for details.

There's currently no management of the cached files, so manual cleanup is required. However I plan to add a few different methods.
Lord Crc (administrator)
2012-05-25 17:37

Seems the implementation works as expected, I'm resolving this.

Additional caching schemes can be added as new requests.

- Issue History
Date Modified Username Field Change
2009-11-06 01:56 psor New Issue
2009-11-06 03:47 jeanphi Note Added: 0001685
2010-03-17 10:13 jeanphi Target Version => 0.8RC1
2011-02-03 03:39 jeanphi Target Version 0.8RC1 => 1.0
2012-01-14 21:28 Omniflux Note Added: 0003290
2012-01-14 23:08 Lord Crc Note Added: 0003292
2012-01-15 14:30 Omniflux Note Added: 0003294
2012-01-19 03:52 Lord Crc Note Added: 0003316
2012-01-19 05:40 Lord Crc Assigned To => Lord Crc
2012-01-19 05:40 Lord Crc Status new => assigned
2012-01-19 05:42 Lord Crc Note Added: 0003317
2012-01-19 05:44 Lord Crc Note Edited: 0003317 View Revisions
2012-01-19 19:20 Omniflux Relationship added related to 0001188
2012-05-10 22:00 Lord Crc Note Added: 0003392
2012-05-10 22:00 Lord Crc Status assigned => feedback
2012-05-10 22:00 Lord Crc Mercurial Changeset # => cb3265a7cf69
2012-05-10 22:00 Lord Crc Requires Documentation Update => No
2012-05-25 17:37 Lord Crc Note Added: 0003419
2012-05-25 17:37 Lord Crc Status feedback => resolved
2012-05-25 17:37 Lord Crc Fixed in Version => 1.0RC1
2012-05-25 17:37 Lord Crc Resolution open => fixed
2012-09-11 09:11 jeanphi Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker