If I select some items of the model using-
viewer.select(dbids, viewer.model, Autodesk.Viewing.SelectionType.OVERLAYED)
and then try to zoom in/out or rotate the model, the viewer gets slower. But if I select some items using mouse click it doesn't affect the viewer at all.
If I select items using-
viewer.select(dbids, viewer.model, Autodesk.Viewing.SelectionType.REGULAR)
the viewer first hides everything except the selected items and a moment later shows up. It also hide some parts of the selected item(s). The navigation is smooth now.
This is before selection-
This is after selection-
Is there any way to overcome this slowness and the hidden parts issue.
Let me first explain the difference between the overlaid and regular selection highlighting:
Overlaid highlighting means that the selected objects are rendered twice. Once with their standard material, and once with the overlay material (so that they can be seen through obstacles as well). Of course, this doubled rendering may have significant impact on performance, especially if you select many objects (for example, by selecting a group of a large number of objects in the model browser).
Regular highlighting was introduced to mitigate the performance problems. In this case, instead of rendering the selected objects twice, they're simply rendered once, with a specific color tint applied to their regular materials. The drawback of this approach is that the selected objects are not visible through obstacles.
Now, to your problem: "regular" selection highlight is definitely the right way to go if the "overlay" highlighting is slow, but the fact that parts of your model disappear is strange. I'm thinking there might be a problem with the model itself. Perhaps it's too granular or tessellated (has too many parts or triangles), so applying the "selection tint" to all the selected parts takes unusually long time. Could you please try both the "overlay" and the "regular" selection with another type of 3D model? If it works well, you may need to look at the settings of the application that's creating this problematic model, and see if you can decrease the tessellation levels.
Related
We currently use the model derivatives API to upload 3D models and later visualize them in a browser with the Autodesk Viewer v7 (previously Forge Viewer).
For different reasons we have been trying to hide and show parts of the model, but to do so in some cases we need to be able to hide geometric pieces of some elements while still being able to see the rest. For example if we had an element in gray (see image below) we would like to make the part of the element in red transparent.
I have looked into the Viewer API docs and there are functions that allow showing and hiding complete elements, but not cutting elements along a custom path.
While the docs mention the overlay functionality which enables us to add custom geometries by interacting with the THREE library that the Viewer runs on, drawing a copy of the whole model seems inefficient and prone to giving bad results.
Searching in SO I found that the THREE v71 library (which is the version the Viewer uses) has the possibility of occluding elements with the colorWrite option. See these links for reference:
three.js transparent object occlusion
Occlusion of real-world objects using three.js
I tried implementing something similar by using the colorWrite key when creating a new Three Material in an overlay, but nothing happens. This makes me think that either the Autodesk Viewer overwrites the render order (which makes sense) or openly ignores the colorWrite option. Does anyone know why and if there is a workaround for this? Or does anyone know if there is another way to cut an element that I'm not considering?
Please note that we have to do this with multiple elements at the same time and that reuploading the model periodically is not an option for us.
I got the following feedback:
The approach linked in the SO thread doesn't work, because we ignore both the colorWrite material property and the renderOrder mesh property. I also think that the approach would not work as expected in general, because using an invisible object to occlude a part of another object would always be view-dependent, and also occlude other objects in the background (so it wouldn't just 'cut out' a part of a single object).
Generally, this is not really a use-case for LMV, because it's a viewing tool, not a solid modelling tool.
Cut planes might help to get some of what you want, but they also have limitations:
It's possible to define multiple section planes to construct a 'shape' (that's also what the section box does internally). But since they are infinite, you wouldn't be able to cut away parts of one object, but not other objects (or other parts of the same object that intersect the cutplane). They're also designed to be 'outward' facing. The section box, for example, can only be used to narrow the scene down to some elements of interest. It's not possible to do the opposite, i.e. cut out some inner part of the design and keep everything around it.
This is what the section box could offer:
I am rendering a scatter plot every 5 seconds where the X-axis denotes time and Y-axis denotes a set of names ordered alphabetically.
A set of data points (say, 'X's) can optionally be grouped into a category and so I use a color to show this. Therefore all 'X's with the same color belong to the same category and so on.
Problem: I have tens of thousands of 'Name's and they can appear randomly on the graph at some point in time. The real purpose is to provide the user with a graph that provides the ability to monitor these names. Therefore, every time I render the graph, I get the list of points to be rendered and the underlying graph library: Flotr2 takes care of assigning colors to the sets of points. Therefore, if the dataset contains two categories of points, it assigns two colors and if a point belonging to a new category arrives, it assigns a third color. As a result of this, what I am observing due to this is a flicker effect:
And when the point disappears, the colors revert back to the ones before. Is there a good way to solve this problem? I have two specific problems:
Colors keep changing for every new point being added
A new point added somewhere shifts every other point vertically in either direction. For instance, if Category 2.5 is added, it ends up shifting Category 2 down and Category 1 up because the alphabetical order should be preserved.
In a scenario which is highly dynamic, such a graph tends to be useless because of the dynamism it shows visually. One obvious solution I can think of is to pre-allocate space for all points and all categories possible in the graph so that an appearance of a new point will not change anything but it just draws a point somewhere. However, I am not clear if this approach is ideal for large data sets where the set of names and categories change often.
Is there a good way to solve this problem? I am open to other graph types that mitigate this problem. In short, I want a real-time display that is capable of showing the appearance of new names on a time axis.
This is my first posted question despite using StackExchange for a few years now. I've been stuck for quite some time trying to figure out this issue with OpenLayers. The problem is as follows:
I have a bunch of features plotted on a map and am able to select features in various ways (e.g. drawing a box around them, clicking on individual features, entering a zip code that selects all features within that zip code, etc.). This all works fine. The issue is that I have a clustering strategy on the features layer and when I zoom out, currently selected features get clustered together with unselected features and those unselected features will become selected when I zoom back in. What I'm trying to accomplish is to NOT have the previously unselected features become selected after clustering.
This behaviour (keeping selection of subfeatures after zooming in with selected cluster) is buried quite deep inside of Strategy.Cluster code. One solution would be to get deep into the code of Strategy.Cluster and making it remember really selected features and select only those on zoom in (actually - on reclustering, or calling Strategy.Cluster.cluster()). Second would be to track the selected features outside of openlayers by subscribing to event featureselected and reselecting features on zoomend.
I need to create a dropdown, which can contain 100s of options.
I need a scrollbar to appear and be consistent across all browsers.
Google came up empty: Is there a good URL that describes if this is consistent or not?
I would strongly recommend against having a scrollable select with 100s of options for usability reasons.
With exception of one corner case, navigating (both searching in, and selecting from) that list is a really really hard and very annoying to the user.
The UI design reasoning is that it requires:
Wide mouse gesture (tiring), followed by immediate precise stop (hard to do because of inertia)
Very difficult to use interface of a scrollbar (extra crap points for scrollbar being in the middle of the page instead of on the right side) - see Jacob Nielsen's and others' usual ranting about difficulties of using scrollbars and general evil of anything too long that requires much scrolling.
Eyes need to scan whole page worth of menu up and down and back, all the time. very tiring.
Here is a set of bad examples
[ the corner case is when all the option names are uniformly distributed across the alphabet (as far as the first letter), which allows somewhat-possible keyboard-only navigation in the drop-down via pressing the first letter of an option ].
A proper UI solution is to have a select whose contents are dynamically populated based on a search field - either typed text (think Google's new search box, or browser's address bar) or sometimes checkboxes/radio buttons.
BTW, sub-menu solutions also suck for mouse navigation - minor twitch of the wrist and you lost all of the pointing work.
I apologize that this answer is not an answer to "how do you solve my technical problem", but I am of a very strong opinin that you're solving the wrong problem in the first place.
HTH.
The short answer is no, for the standard HTML select element and the requirements you describe.
However, do you know you can set the size attribute for how many rows are visible at one time? AFAIK this will force scrolling in all browsers, but it isn't a drop down. Like this:
<select size="10">
<option>etc</option>
...
</select>
There is also the possiblity of optgroup to split the options into categories.
If you have many categories you could do what I did on one site and use this jQuery click menu, using the click function to set a hidden field. So now I have a dropdown with sub-categories and it's quite easy to find the right option.
I'm creating a space game in actionscript/flex 3 (flash). The world is infinitely big, because there are no maps. For this to work I need to dynamically (programatically) render the background, which has to look like open space.
To make the world feel real and to make certain places look different than others, I must be able to add filters such as colour differences and maybe even a misty kind of transformation - these would then be randomly added and changed.
The player is able to "scroll" the "map" by flying to the sides of the screen, so that a certain part of the world is only visible at once but the player is able to go anywhere. The scrolling works by moving all objects except for the player in the opposite direction, making it look like it was the player that moved into that direction. The background also needs to be moved, but has to be different on the new discovered terrain (dynamically created).
Now my question is how I would do something like this, what kind of things do I need to use and how do I implement them? Performance also needs to be taken into account, as many more objects will be in the game.
You should only have views for objects that are within the visible area. You might want to use a quad tree for that.
The background should maybe be composed of a set of tiles, that you can repeat more or less randomly (do you really need a background, actually? wouldn't having some particles be enough?). Use the same technique here you use for the objects.
So in the end, you wind up having a model for objects and tiles or particles (that you would generate in the beginning). This way, you will only add a few floats (you can achieve additional performance, if you do not calculate positions of objects, that are FAR away. The quad tree should help you with that, but I think this shouldn't be necessary) If an object having a view leaves the stage, free the view, and use the quad tree to check, if new objects appear.
If you use a lot of objects/particles, consider using an object pool. If objects only move, and are not rotated/scaled, consider using DisplayObject::cacheAsBitmap.