krpano 1.19-pr9 / 1.19-pr10 / 1.19-pr11 / 1.19-pr12

  • I downloaded linux version and extracted files, the tools are changed to js implement.
    Is there still command line interface of linux tools? ( depend on node.js ?)

    Sorry, but I'm not sure what you mean, nothing had been changed here - the command line tools are still available for all platforms.

  • That's also related to the layout problems mentioned a few posts above.
    There will be a new krpano release in the next hours where this will be fixed.

    That's also related to the layout problems mentioned a few posts above.
    There will be a new krpano release in the next hours where this will be fixed.


    pr10 also can not wrap when renderer is webgl

    hotspot also have this bug

    Edited once, last by tmhok (May 11, 2017 at 9:12 AM).

  • Sorry!
    I extracted file by wrong way!
    (I had used 'unzip' command instead of 'tar' command. But I don't know why javascript files had been appeared....)

  • Hi,

    pr10 also can not wrap when renderer is webgl
    ...
    html="Text...Text...Text...Text...Text...Text...Text..."
    ...

    That's not a bug - only 'word'-wrapping is possible, but no hyphenation or breaking within one word. That means a line can only break on white-spaces, but not within a word. And your text is basically one long word, try putting spaces between the texts and it will automatically line break.

    But if you want breaking of the word itself, it would be possible to add the 'word-break:break-all' css style, e.g.:

    Code
    css="...; word-break:break-all;"

    but that would only work for layers, the webgl textfield hotspots don't support that functionality.

    Best regards,
    Klaus

  • Hi,

    That's not a bug - only 'word'-wrapping is possible, but no hyphenation or breaking within one word. That means a line can only break on white-spaces, but not within a word. And your text is basically one long word, try putting spaces between the texts and it will automatically line break.

    But if you want breaking of the word itself, it would be possible to add the 'word-break:break-all' css style, e.g.:

    Code
    css="...; word-break:break-all;"

    but that would only work for layers, the webgl textfield hotspots don't support that functionality.

    Best regards,
    Klaus

    OH,no white-spaces between Chinese characters。

    if english is

    i love you so much 4 white-spaces

    in chineses
    我非常爱你 0 white-space

    *confused* layer is fine,but hotspot still

    Edited once, last by tmhok (May 11, 2017 at 10:31 AM).

  • OH,no white-spaces between Chinese characters

    Hmm... as written for the WebGL textfield everything needs to be processed (coded) manually. So to be able to support that, I would need to implement a special word-breaking for Chinese (or other languages), but I have no language knowledge about that and a language specific processing would be a bit out of scale...

    I could only image maybe adding a feature for a 'character-wise' breaking (like the css 'word-break:break-all' setting), that means allow breaking after each character (although that might be slow to process because every character need to measured separately), but then I still don't know if that would be okay for the particular language...

  • Hmm... as written for the WebGL textfield everything needs to be processed (coded) manually. So to be able to support that, I would need to implement a special word-breaking for Chinese (or other languages), but I have no language knowledge about that and a language specific processing would be a bit out of scale...

    I could only image maybe adding a feature for a 'character-wise' breaking (like the css 'word-break:break-all' setting), that means allow breaking after each character (although that might be slow to process because every character need to measured separately), but then I still don't know if that would be okay for the particular language...


    mainly chineses would had that problem

  • Hi,

    i found that when the 'roundedge' of textfields is larger then 50% of the height we get a 'funny effect.
    It was not like that.
    Can you change that behaviour back? so that it when the value is too big it does not 'funny'.
    Or does it has another reason?
    *g*

    http://www.virtualtuur.com/krpano/11910/1/

    Tuur *thumbsup*

  • hi klaus,

    i'm merging to 1.19pr10 and noticed,
    that when you build a panotour
    there are plugins missing in the builds:

    snow, showtext, radar, options, moretweentypes, gyro, fps, editor, compass and combobox
    are missing if you use the make pano scripts.

    i copied them from the templates folder,
    but i suspect it was not intended to be like that... (?)

    cheers, index

  • Hi,

    found that when the 'roundedge' of textfields is larger then 50% of the height we get a 'funny effect.
    It was not like that.
    Can you change that behaviour back? so that it when the value is too big it does not 'funny'.
    Or does it has another reason?

    The reason is new WebGL textfield support - as written there everything needs to be done and coded manually - so too the rendering of the rounded background shape - and there I haven't implemented yet the limitation of too large rounded edge values (a tricky part). But that's already on my list and will be there in next releases.

    If this is a direct problem, the setting renderer="css3d" could be used. Then the textfield hotspot will be rendered by HTML+CSS as in previous versions.


    i'm merging to 1.19pr10 and noticed,
    that when you build a panotour
    there are plugins missing in the builds:

    snow, showtext, radar, options, moretweentypes, gyro, fps, editor, compass and combobox
    are missing if you use the make pano scripts.

    i copied them from the templates folder,
    but i suspect it was not intended to be like that... (?)

    There was no change here!
    The files that will be automatically copied when using a droplet are defined in the .config (and the there included .skin) files via the xmltemplate_additional_file setting.

    E.g. have a look into the vtourskin119.skin (used by the VTOUR droplets) and the defaultbuttons.skin (used by the NORMAL droplets) files.


    MAKE OBJECT droplet.bat is missing too since 1.19 pr9, is there a html5 version on it's way ?

    Yes, I've removed that droplet for the moment because there is no HTML5 support yet.
    But only the droplet itself was removed, all related files for it are still there.

    Best regards,
    Klaus

  • So maybe I'm mixing some stuff up here but I'm still not able to use text together with our VR panoramas - I'm trying to show a cursor + text in VR - however it is not showing anything (no cursor, no text) as soon as I try to add a text layer (linked to parent).

    I've followed the examples here in the forum - in non-VR mode it works great but as soon as I switch to VR mode everything disappears. If I remove the textfield layer it shows the cursor also in VR mode - still no text.

    I thought it should work in pr9 and pr10? Is there a setting I have to take care of to use WebGL or what is it?

  • Hi,

    So maybe I'm mixing some stuff up here but I'm still not able to use text together with our VR panoramas - I'm trying to show a cursor + text in VR - however it is not showing anything (no cursor, no text) as soon as I try to add a text layer (linked to parent).

    Only <hotspot> text elements itself are supported for WebGL now, but no <layer> elements attached to a hotspot.
    When a hotspot gets children elements, the hotspot rendering switches automatically to CSS3D mode.

    VERY ANNOYING : AUTOLEVEL=OFF in basicsettings.config still REMAP RICOH IMAGES!!!

    Sorry, a stupid bug from me - I have first added the autoleveling support to the makepano tool and tested it there successfully of course - and than later autoleveling was quickly added also to the sphere-to-cube tool (enabled there by default) - and because the makepano tool is internally also using the sphere-to-cube tool, it's now the default-enabled-autoleveling from the sphere-to-cube tool which is doing the leveling here...

    This will be fixed in the next release.

    Best regards,
    Klaus

  • thanks :)

    remap option is great for Ricoh, but why it automatically involve changing image horizontal offset? i mean it doesn't level the image only, it also shift it horizontally

    question regarding parsegps, why does it involve y position only in prealign?

    thanks

  • emap option is great for Ricoh, but why it automatically involve changing image horizontal offset? i mean it doesn't level the image only, it also shift it horizontally

    That's 'to north' all the images. The Ricoh EXIF information provide roll, pitch and heading all these will be used for the leveling.

    question regarding parsegps, why does it involve y position only in prealign?

    There is also a small bug here - the prealign with the heading information only should be normally only applied when the image was not remapped and not prealigned by the leveling. That will be also fixed in the next release.

    Best regards,
    Klaus

  • great!

    what if we want to level but don't want to "north" the image? can you make an option for this?

    is there a way to generate equirectangular preview and not cubestripe?

    thanks

  • Hi,

    what if we want to level but don't want to "north" the image? can you make an option for this?

    Okay, added to todo-list.
    Any ideas how that option should be done or be named?
    E.g. settings like:
    autolevel=prealign_without_heading
    autolevel=remap_without_heading
    don't look very well...

    Quote

    is there a way to generate equirectangular preview and not cubestripe?

    Set cspreview to false:
    https://krpano.com/tools/kmakemultires/config/#preview

    Best regards,
    Klaus

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!